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ABSTRACT 


The  development  of  an  intelligent  autonomous  vehicle  that  can  perform  high  risk 
missions  or  operate  in  environments  too  hazardous  for  humans  has  been  a  long 

*  standing  quest  of  the  military  community.  The  Autonomous  Platform  Simulator 
(APS)  uses  the  flexibility  and  power  of  realistic  graphical  simulation  to  provide  a  low 
cost  testbed  for  the  study  of  real-time  path  planning  algorithms  and  control  strategies 
without  the  commitment  of  resources  involved  in  building  a  prototype  system.  It  is  a 
bridge  between  the  theoretical  study  of  an  abstract  A1  path  planning  problem  and 
applied  research,  producing  concrete  performance  measurements  >mrler  malistir 
conditions. 

APS  consists  of  one  or  more  vehicle  simulators,  each  implemented  on  a  Silicon 
Graphics  IRIS/4D-70GT  graphics  workstation.  One  vehicle  simulator  is  linked  with 
^  an  A I  agent  path  planner,  implemented  on  a  pair  of  Symbolics  A1  workstations  using 

the  Automated  Reasoning  Tool  development  shell. 

*  System  trials  demonstrated  that  APS  w'as  able  to  achieve  real-time  path  planning 
and  guidance  of  a  realistically  depicted  ground  vehicle  navigating  using  digitized  data 
of  actual  terrain.  Communication  bottlenecks  currently  limit  the  ability  to  make  direct 
comparisons  between  human  and  machine  control  but  the  system  holds  promise  to  fill 
the  gap  as  a  pre-prototype  autonomous  platform  simulator. 
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I.  INTRODUCTION 


A.  PROBLEM  STATEMENT 

The  development  of  a  truly  autonomous  vehicle  is  a  long  sought  after  goal 
[DODSCI83,  WEISN&89].  The  more  autonomy  and  intelligence  such  a  vehicle  has, 
the  more  it  can  replace  humans  for  the  performance  of  hazardous,  strenuous,  or  repeti¬ 
tive  tasks.  Research  in  autonomous  vehicles  has  largely  focused  on  the  development 
of  control  systems  that  totally  replace  human  direction  and  move  human  interaction  to 
higher  levels  of  generalization  and  abstraction.  Yet  no  broad  comparison  has  been 
done  of  the  performance  of  a  human  operator  with  varying  levels  of  automated  sup¬ 
port,  versus  purely  autonomous  control.  The  objective  of  this  research  is  to  create  an 
Autonomous  Platform  Simulator  (APS.)  in  order  to  provide  a  facility  for  such  compari¬ 
sons.  Performance  measurements,  taken  under  varying  combinations  of  human  and 
AI  agent  control  over  a  simulated  vehicle  navigating  a  tactical  cross-country  route, 
provide  the  yardstick  to  compare  the  studied  modes  of  operation. 

One  of  the  major  tasks  that  an  autonomous  vehicle  must  perform  is  to  plan  a 
path  to  reach  its  goal  and  then  navigate  along  that  path.  There  are  many  algorithms 
for  calculating  (planning)  an  optimal  pain  based  on  some  traversal  cost  criteria 
[RICHDG87  contains  an  excellent  survey  of  path  planning  methods].  In  the 
construction  of  an  autonomous  vehicle  prototype,  one  methodology  is  usually  chosen 
and  then  frozen  by  the  investment  in  the  implementation.  Another  aim  of  the  APS 
system  is  to  provide  a  means  for  comparing  the  performance  of  path  planning 
algorithms  in  a  practical  setting  using  real  world  terrain  data.  The  replacement  of  an 
actual  vehicle  with  a  realistic  graphical  simulation  is  desirable  for  this  research 
because  different  algorithms,  hybrid  control  configurations,  and  other  teatures  can  be 
studied  without  the  cost  of  building  a  physical  system,  the  risk  of  damage  to  an  actual 
vehicle,  or  the  risk  of  injury  to  a  human  driver.  For  this  research  effort,  the  physical 
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vehicle  and  its  onboard  navigation  and  control  systems  are  simulated  on  a  Silicon 
Graphics  IRIS/-1D-70GT  graphics  workstation. 

L  uie  APS  system  the  simulated  vehicle  navigates  along  a  pre-determined  path 
toward  a  known  goal.  The  path  is  produced  by  either  an  A1  agent  or  a  human  planner 
from  global  terrain  data,  such  as  a  map.  which  does  not  contain  the  location  of  obsta¬ 
cles,  such  as  minefields,  which  may  force  a  deviation  from  the  original  path.  Various 
performance  measures  are  monitored  to  evaluate  different  combinations  of  autonomous 
and  human  control.  The  AI  agent  planner  is  implemented  on  a  dedicated  A I  w  orksta¬ 
tion,  a  Symbolics  3650.  The  expert  system  shell  used  in  this  study  is  ART.  produced 
by  Inference  Corporation  [INFRNC85]. 

In  developing  an  autonomous  vehicle  simulation  with  selectable  modes  of  vehi¬ 
cle  control  and  path  planning,  four  distinct  modes  of  operation  are  implemented  charac¬ 
terized  by  whether  a  human  operator  or  AI  agent  is  performing  the  function.  The  four 
combinations  studied  are: 

1  -  Human  path  planning  and  a  human  driver. 

2  -  Human  path  planning  wiui  an  autopilot  capable  of  follow  ing  the  calculated  path 

3  -  Path  planning  by  an  expert  system  with  a  human  driver  controlling  the  vehicle 

based  on  received  path  points. 

4  -  Total  autonomous  (hands-off)  control. 

The  hierarchy  involved  in  these  tasks  recognizes  another  level  above  the  two  so 
far  discussed,  that  of  mission  planning,  which  designates  the  vehicle's  final  objective  or 
goal  point  of  the  path.  In  APS,  the  output  of  the  mission  planning  process  is  considered 
a  given  and  is  always  entered  by  the  human  commander. 

B.  THESIS  ORGANIZATION 

The  work  done  in  this  thesis  breaks  down  into  two  major  areas:  vehicle  simula¬ 
tion  and  path  planning.  Work  done  in  the  vehicle  simulation  arena  was  performed  by 


Teter.  Work,  done  in  the  path  planning  arena  was  performed  by  Shannon.  The  commu¬ 
nications  w'ork  was  completed  by  both  authors. 

Chapter  II  contains  an  overview  of  previous  work  done  in  path  planning,  communi¬ 
cations,  and  real-time  vehicle  simulation  that  relate  to  this  study.  Chapter  III  con¬ 
tains  a  detailed  discussion  of  the  development  of  the  algorithms  and  simulator 
software  developed  during  this  study.  This  chapter  also  covers  the  simulator  vehicle 
environment,  the  characteristics  that  allow  the  simulated  vehicle  to  react  realistically, 
and  detailed  discussions  of  path  planning  algorithms.  Chapter  IV  contains  discus¬ 
sions  on  the  final  system  implementation.  Chapter  V  examines  the  final  APS  system. 
Finally,  Chapter  VI  contains  the  authors’  views  regarding  the  limitations  of  this  study 
and  possible  areas  for  fu'ure  research. 


U.  BACKGROUND 


This  chapter  provides  a  survey  of  previous  work  in  graphical  vehicle  simulators 
and  path  planning  with  special  emphasis  on  research  done  at  the  Naval  Postgraduate 
School  that  laid  the  foundation  for  the  APS  project. 

A.  VEHICLE  SIMULATORS 

The  vehicle  simulator  component  of  the  APS  system  evolved  oui  of  an  effort  to 
enhance  the  Moving  Platform  Simulator  (MPS)  [FICHTN&88],  a  real-time  visual 
simulation  of  the  Fiber  Optically  Guided  Missile  (FOGM'i,  ground  vehicles,  and  three 
dimensional  terrain,  which  was  itself  the  result  of  a  continuing  senes  of  real-time 
visual  simulations  of  ground,  sea,  and  air  platforms  constructed  by  students  at  the 
Naval  Postgraduate  School  [OLIVER&87.  SMI1HD&87,  MCNKLE&88, 
WINN&89], 

APS  was  first  implemented  using  the  Firing  Platform  Simulator,  FPS,  a  close 
cousin  of  MPS.  FPS  was  a  class  project  which  added  multiple  independent  views  and 
ground  vehicles  that  could  engage  each  other  with  weapons  systems.  Since  MPS  is 
the  direct  ancestor  of  both  APS  and  FPS,  its  descnption  provides  an  understanding  of 
the  context  upon  which  the  vehicle  simulator  was  built. 

1.  The  Moving  Platform  Simulator 

The  Moving  Platform  Simulator  [FICHTN&88]  was  deve’oped  at  the  Na¬ 
val  Postgraduate  School  on  a  Silicon  Graphics,  Inc.  IRIS  4D/70-GT  graphics  worksta¬ 
tion.  MPS  allows  a  user  to  select  a  view  from  either  a  ground  vehicle  or  FOGM 
missile  and  guide  the  platform  over  a  three-dimensional  view  of  a  10x10  kilometer  ar¬ 
ea  of  Fort  Hunter-Liggett,  California.  The  FOGM  missile  i.  able  to  target,  track,  and 
destroy  vehicles  on  the  ground.  The  elevation  data  for  the  simulation  was  provided  by 
the  U.  S.  Army’s  Combat  Developments  Experimentation  Center  (CDEC)  at  Fort 
Ord,  California.  MPS  accepts  standard  digital  map  data  for  other  areas  of  the  world. 
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Ground  vehicles  in  MPS  are  controlled  by  dials  on  a  peripheral  input  de¬ 
vice.  Control  response  is  immediate.  Changes  in  vehicle  course  and  speed,  for  exam¬ 
ple,  are  effective  during  the  next  display  cycle,  making  them  essentially 
instantaneous.  The  maior  portions  of  MPS  adopted  unchanged  for  APS  are  the  dis¬ 
play  routines,  terrain  representation,  window  manager  interface,  FOGM  modeling, 
and  the  overall  program  structure. 

2.  The  Firing  Platform  Simulator 

The  Firing  Platform  Simulator  was  a  class  project  that  enhanced  the 
ground  platform  capabilities  in  MPS  by  adding  a  more  realistic  image  of  a  tank 
(Figure  2-1),  multiple  independent  viewing  axes,  and  engagement  between  ground 
vehicle  weapon  systems.  A  set  of  driver’s  controls  were  added  using  a  mouse  to  let 
the  user  manipulate  the  throttle,  brakes,  and  steering. 

3,  Vehicle  Motion  Modeling 

Realistically  simulating  the  response  of  vehicles  to  controls,  such  as 
throttle  and  steering,  and  to  changes  in  the  terrain,  is  often  neglected  in  a  graphical 
simulation  because  a  complete  model  of  the  physics  of  motion  would  be  both 
analytically  complex  and  computationally  expensive.  Complete  modeling  of  the 
mechanics  of  vehicle  motion  is  a  complex  proposal  [BARNAC64],  Much  of  the 
modeling  effort  of  engineers  has  therefore  focused  on  analyzing  a  smaller  subproblem 
such  as  the  characteristics  of  a  vehicle  subsystem  like  the  steering  or  suspension. 
Past  work  at  NPS,  such  as  that  of  Tan  [TAN86],  has  studied  various  control 
algorithms  for  an  autonomous  vehicle  following  a  curving  road  at  constant  velocity.  In 
Tan’s  study  vehicle  mechanics  were  modeled  by  numerically  integrating  second  order 
equations  of  motion  for  an  idealized  point  mass.  Numerical  integration  provides  for 
accurate  answers  to  vehicle  motion  equations,  but  at  the  cost  of  extensive 
computation.  The  modeling  requirements  of  APS  are  both  more  general  and  more 
constrained:  more  general  in  realistically  modeling  the  effects  of  control  inputs  and  the 
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effects  of  vehicle  interaction  with  varying  terrain  -  more  constrained  by  not  being  able 
to  afford  an  increase  in  the  computational  burden  from  modeling  because  of  the  effect 
on  overall  performance. 

Real-time  graphical  moving  platform  simulations  often  consume  most  of 
the  computing  resources  of  a  graphics  system  in  realistically  depicting  terrain  and  ve¬ 
hicles  [FICHTN&88:  og  72].  Many  graphics  researchers  shy  away  from  more  realis¬ 
tically  modeling  of  the  effects  of  steering  and  terrain  in  the  belief  that  the  problem  is 
too  hard  and  the  necessary  code  would  be  too  slow.  What  is  sought  for  APS  is  a  sim¬ 
plified  model  of  vehicle  motion  and  control  response  designed  for  a  class  of  ground 
platforms  moving  off-road  across  varying  terrain.  An  interesting  candidate  vehicle 
model  was  developed  by  Ross  at  NPS  [ROSS89],  Ross's  work  provided  a  thorough 
but  computationally  simple  model  of  vehicle-terrain  interaction  and  energy  costs 
while  traversing  varied  terrain  regions.  Unfortunately,  his  model’s  assumption  of  con¬ 
stant  velocity  and  its  requirement  for  homogeneous  terrain  patches  make  it  unsuitable 
as  a  basis  for  the  APS  vehicle  simulator.  However,  his  work  has  great  potential  as 
an  alternate  cost  function  for  path  planning. 

B.  AUTONOMOUS  VEHICLES 

Research  in  autonomous  vehicles  received  great  impetus  in  recent  years  from 
DoD’s  Strategic  Computing  Initiative  [DODSCI83]  which  called  for  a  push  of 
"machine  intelligence  technology"  in  applied  research.  One  of  its  three  demonstration 
projects  is  the  Autonomous  Land  Vehicle  program.  Much  of  the  work  generated  on 
autonomous  vehicles  has  focused  on  vision  systems,  local  obstacle  avoidance,  such 
as  FMC  Corporation’s  Autonomous  Vehicle  [NTTAO&88],  and  road  following 
guidance,  such  as  Martin  Marietta’s  ALV  [LOWRIE85],  Since  APS  doesn’t  have 
local  obstacles  to  avoid  or  roads  to  follow,  such  research,  while  stimulating,  lacks 
direct  applicability.  The  autonomous  vehicle  prototypes  do,  however,  provide  insight 
into  the  functional  decomposition  of  the  problem  of  autonomous  vehicle  navigation  and 
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control.  For  example,  both  autonomous  vehicles  mentioned  above  separate  path 
planning  from  vehicle  navigation  and  control,  to  the  extent  of  having  different 
hardware  perform  those  functions. 

The  most  productive  source  of  techniques  for  modeling  vehicle  motion  and 
response  turned  out  to  be  basic  physics  texts  such  as  Marion’s  Classical  Dynamics 
[MARION70]  or  the  late  Richard  Feynman’s  Physics  Lecture  Series  [FEYNMN63], 
Robotics  applications  [FRANK69]  also  provide  some  usable  techniques.  Starting 
then,  from  the  solid  ground  of  physics,  albeit  with  several  simplifying  assumptions, 
the  iterauve  nature  of  the  graphics  drawing  loop  can  be  used  to  break  vehicle  motion 
into  small  enough  increments  so  that  all  equations  of  motion  can  be  modeled  with 
functions  of  no  higher  than  first  order  terms  and  without  numeric  integration.  More  on 
this  topic  is  presented  in  Chapter  III. 

C.  PATH  PLANNING 

The  task  of  planning  a  path  across  a  known  region  has  been  classified  as  a 
weighted-region  problem  [RICHBG87:  pg  15].  The  weighted-region  problem  requires 
finding  the  optimal-cost  path  between  two  known  points  given  an  appropriate  area- 
cost  map.  The  area-cost  map  is  described  as  a  two  dimensional  region  that  is  divided 
into  sub-regions  containing  a  value  of  traversal  for  each  sub-region.  Solving  the 
weighted-region  problem  requires  searching  this  two  dimensional  region.  There  are 
many  strategies  that  can  be  applied  to  this  problem  of  path  planning.  Each  strategy 
has  unique  characteristics  that  determine  its  suitability.  Two  areas  that  have  a  major 
impact  on  path  planning  are  terrain  representation  and  search  methods. 

1.  Terrain  Representation 

Natural  terrain  is  generally  not  discrete  nor  clearly  defined  by  regular 
boundaries.  A  variety  of  terrain  models  are  used  to  depict  natural  terrain.  The  choice 
of  terrain  representation  affects  the  choice  of  the  search  method  used,  and  conversely 
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the  choice  of  a  particular  search  method  limits  the  terrain  representations  that  can  be 
used. 

a.  Cartesian  Grids 

Regular  geometric  grids  a^e  used  to  divide  the  terrain  into  small  regu¬ 
lar  cells  that  are  used  to  classify  some  aspect  of  the  terrain.  In  work  done  by  Felnoe- 
lter,  [FELHOE88:  pg  36-37]  slope  data  derived  from  a  DMA  source  file  of  Fort 
Hunter-Liggett  is  used  to  classify  each  cell  of  the  region.  A  wavefront  search  method 
can  then  applied  to  this  type  of  region  representation  to  find  the  optimal  path  between 
two  points  [ROWE&88:  pg  2], 

b.  Hierarchical  Models 

A  hierarchical  terrain  representation,  as  used  by  Metea  and  Tsai 
[METEA&87],  is  a  variation  of  the  Cartesian  method  used  above,  and  is  used  to  di¬ 
vide  terrain  into  increasingly  fine  geometric  grid  cells.  The  lowest  level  contains  the 
highest  resolution  data.  Each  cell  within  a  level  contains  a  single  number  that  is  asso¬ 
ciated  with  the  cost  of  traversal.  At  the  lowest  level,  this  number  is  normally  a  direct 
representation  of  some  aspect  of  the  patch  of  terrain  represented.  At  each  succeeding 
level,  the  values  of  the  cells  of  the  preceding  level  that  are  contained  in  a  cell  of  the 
next  level  are  used  to  calculate  the  value  of  that  cell. 

Alternative  forms  of  hierarchical  terrain  representation  [KUAN84, 
ROSS89]  move  away  from  the  Cartesian  grid  representation.  These  models  group  re¬ 
gions  from  a  lower  level  that  have  similar  representational  value  into  larger  regions  at 
succeeding  levels.  The  salient  point  of  this  approach  is  that  hierarchical  terrain  mod¬ 
els  group  terrain  information  from  a  lower  level  into  larger  regions  at  higher  levels. 

c.  Homogeneous  Model 

Homogeneous  terrain  representation  [ROSS89]  groups  contiguous 
points,  with  identical  costs  of  traversal,  within  an  arbitrary  convex  polygon.  The  ho¬ 
mogeneous  terrain  model  allows  large  areas  of  terrain  to  be  grouped  and  stored  effi¬ 
ciently  in  the  terrain  data  base.  It  also  removes  the  directional  biases  imposed  on  the 
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terrain  by  Cartesian  terrain  models.  This  representation  is  required  for  certain  types 
of  path  planning  techniques.  One  such  technique  involving  Snell’s  law  uses  the  princi¬ 
ples  of  optics  to  find  paths  across  homogeneous  regions[ROWE87,  ROWE&88], 

2.  SEARCH  METHODS 

The  backbone  of  any  path  planner  is  the  search  algorithm  used.  The  choice 
of  which  search  algorithm  to  use  is  based  on  many  factors.  One  key  factor  already  dis¬ 
cussed  above  is  the  terrain  representation  used.  The  following  search  methods  are 
discussed  briefly  with  emphasis  on  the  impact  of  the  choice  of  terrain  model. 
a.  Wavefront 

Wavefront  planning  needs  a  terrain  model  that  divides  the  search  ar¬ 
ea  into  uniformly  sized  cells,  typically  Cartesian  grid  cells,  where  each  cell  contains 
its  cost  of  traversal.  This  technique  uses  a  modified  breadth  first  search  where  ex¬ 
pansion  is  accomplished  according  to  the  cost  of  traversing  a  cell  instead  of  simply  ex¬ 
panding  from  one  level  of  cells  to  another  [RICHBG87],  Disadvantages  to  this 
approach  are  as  follows: 

(1)  The  terrain  is  cut  up  into  uniform  pieces  no  matter  w  hat  the 
lay  of  the  land  is.  This  is  of  concern  because  the  resolution  of  the  search  region  is  a  di¬ 
rect  reflection  of  the  resolution  of  the  cells  that  make  up  the  search  region. 

(2)  The  wavefront  algorithm  investigated  in  this  thesis  expands 
to  the  8  neighbors  of  a  square  grid  cell,  causing  motion  to  be  restricted  to  straight 
lines,  in  the  vertical,  horizontal,  and  diagonal  directions,  between  a  cells. 

(3)  Finally  there  is  a  certain  amount  of  waste  associated  w  ith 
the  propagation  of  a  wave.  The  entire  wave  must  be  expanded  instead  of  just  follow¬ 
ing  the  most  likely  path.  This  same  problem  of  an  ever  expanding  agenda  is  associat¬ 
ed  with  a  pure  breadth  first  search. 

The  major  advantages  of  this  algorithm  are  that  it  is  guaranteed  to 
find  the  optimal  path  and  it  is  well  understood. 
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b.  Depth-First 

A  depth-first  search  is  used  by  Goodpasture  [GOODPAX7]  to  pro¬ 
vide  motion  planning  for  a  computer  simulation  of  an  autonomous  walking  machine. 
The  depth-first  search  algorithm  is  guaranteed  to  provide  a  path  if  one  exists.  It  how¬ 
ever,  does  not  guarantee  finding  an  optimal  path.  The  first  path  found  is  the  path  cho¬ 
sen.  The  algorithm  used  simply  explores  neighboring  nodes  that  have  not  been 
explored  or  are  not  obstacles.  A  node  is  chosen  that  is  closest  to  the  goal.  This  strat¬ 
egy  is  followed  until  the  goal  is  reacned  or  the  trail  ends.  If  the  trail  ends,  the  algo¬ 
rithm  backtracks  the  path,  marking  the  used  nodes  as  obstacles,  until  it  finds  an 
unexplored  node  to  follow.  If  an  unexplored  node  is  found  the  search  is  continued  as 
before.  If  the  start  point  is  returned  to,  and  no  unexplored  nodes  are  available,  the 
search  fails.  That  is,  no  path  is  possible.  The  depth-first  search  is  best  used  where 
"go"  "no-go"  terrain  features  are  used. 

c.  A  Star  (A*) 

The  A*  search  combined  with  Snell's  law  is  used  to  solve  long  range 
path  planning  problems,  where  the  terrain  is  divided  into  homogeneous-cost  regions. 
Variations  of  Snell's  law  are  used  to  find  possible  paths  to  the  goal,  across  the  homo¬ 
geneous-cost  regions.  Then  the  A*  search  is  performed  using  evaluation  values  de¬ 
veloped  from  the  A*  search  [RICHBG87], 

D.  EXPERT  SYSTEM  SHELLS 

Technology  has  advanced  beyond  the  days  of  using  a  general  purpose  computer 
merely  to  relieve  humans  of  the  tedious  tasks  of  redundant  mathematical  calculations 
or  the  endless  searching  of  records.  It  is  now  possible  to  undertake  more  complex 
tasks  with  improved  accuracy.  Specifically,  the  growing  complexity  of  model 
representation  combined  with  a  limited  understanding  of  the  processes  of  human 
thought  and  reasoning,  have  led  to  the  use  of  logic  oriented  languages  to  help 
represent  rules  used  in  human  decision  making.  Two  such  logic  oriented  languages 


are  LISP  and  Prolog.  But  these  languages  require  the  researcher  to  be  very  closely 
tied  to  the  machine  environment.  With  these  languages,  the  programmer  is  directly 
involved  in  the  detailed  management  of  rules  and  facts.  The  desire  to  remove  the 
burden  of  rule  and  fact  management  has  lead  in  part  to  the  development  of  expen 
system  shells. 

The  use  of  expen  system  shells  as  logical  programming  environments  provides 
an  arena  for  the  development  of  computer  programs  to  solve  problems  otherwise 
difficult  to  formulate.  These  environments  or  shells  provide  such  features  as  backward 
chaining,  forward  chaining,  inheritance,  and  fact  and  rule  management.  Backward  and 
forward  chaining  control  strategies  provide  one  of  the  critical  features  of  expert 
system  shells,  since  these  strategies  constitute  inference  engines.  The  ideal 
inference  engine  allows  rules  to  fire  independently  of  the  order  with  which  the 
programmer  places  the  rules  in  the  program  control  structure.  Actual  inference 
engines  contained  in  expen  system  shells  may  fall  short  of  this  ideal,  but  such  shells 
provide  a  tool  that  allows  programmers  to  think  of  rules  as  independent  islands  of 
action  waiting  for  the  ocean  of  knowledge  around  them  to  provide  the  preconditions  for 
their  firing.  The  expert  systems  shells  available  at  the  Naval  Postgraduate  School  are 
KEE  by  Intellicorp  [INTEL86],  and  ART  by  Inference  Corporation  [INFRNCS5], 

E.  COMMUNICATIONS 

The  real  time  control  of  a  visual  simulation  can  involve  the  use  of  more  than  one 
type  of  architecture.  The  ability  to  transmit  and  receive  control  information  and 
working  data  between  processes  implemented  with  different  architectures  was 
investigated  by  Barrow  [BARROW88].  The  medium  of  communication  between  the 
various  architectures  was  TCP/IP  using  the  Ethernet.  The  principal  forms  of 
communication  investigated  were  I/O  stream  and  broadcast. 

Broadcast  datagrams  were  used  by  Barrow  to  communicate  between  IRIS 
workstations.  They  provided  a  convenient  way  to  send  discrete  messages  without 


12 


connecting  hosts  or  requiring  a  specific  host  address.  This  method  of  communication 
was  not  supported  between  UNIX  TCP/IP  systems  and  the  Symbolics  CHAOSNET, 
so  s.-v.  im  communications  were  used.  The  package  of  routines  developed  supported 
messages  containing  a  single  character  or  number  with  the  UNIX  side  of  the 
connection  required  to  act  as  the  connection  server. 

F.  DEVELOPMENT  SYSTEM  DESCRIPTION 

1.  IRIS  Graphics  System 

a.  SGI  IRIS/4D-70GT  Graphics  Workstation  Description 

The  IRIS/4D  GT  is  a  line  of  high  performance  graphics  workstations 
with  extensive  hardware  support  for  graphics  modeling  that  can  support  the  real-time 
3D  drawing  of  the  large  number  of  polygons  necessary  in  a  realistic  vehicle  simulator 
[ZYDA&88].  This  system  has  the  following  performance  characteristics: 

•  10  MIPS  cpu  (MIPS,  Inc.  R2000  RISC  Processor). 

•  40,000  10  X  10  pixel  quadrilaterals  per  second  (  lighted  &  Gouraud  shaded). 

•  24-bit  Z-buffer. 

•  Parallel  modeling  matrix  operations. 

•  Hardware  transformation  matrix  stack. 


b.  Software 

The  following  software  products  were  used  in  the  development  of  the 

APS  system: 

•  SGI  C  (MIPS)  compiler. 

•  UNIX  system  V  Operating  System  with  TCP/IP  Network  extensions. 

•  SGI  4Sight™  Window  Manager.  4Sight  manages  screen  and  I/O  resources  of 
the  IRIS  workstation.  It  supports  graphics  clients  using  the  SGI  graphics  li¬ 
brary  as  well  as  programs  written  for  NeWS  and  XWindows[SGI4UG88]. 
APS  runs  as  a  client  under  the  4Sight  server  using  the  graphics  library  inter¬ 
face  for  maximum  performance.  This  gives  APS  the  flexibility  of  running  in  a 
window  of  arbitrary  size  and  location.  The  window  manager  also  provides  the 
popup  menu  services  used  extensively  by  APS.  4S ight  also  provides  a  font 
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manager  to  scale  and  render  text  fonts  in  prompts,  legend  text  and  displayed 
messages. 

2.  Symbolics 

a.  Symbolics  3600 

Symbolics  3600  workstations  were  chosen  to  perform  the  path  plan¬ 
ning  tasks  of  APS.  The  Symbolics  family  of  symbolic  processing  machines  are  de¬ 
signed  with  a  proprietary  CPU,  which  allows  these  systems  to  have  LISP  and  other 
symbolic  programming  languages  implemented  more  efficiently  and  effectively  than 
conventional  computers.  Much  of  the  efficiency  and  effectiveness  of  the  Symbolics 
workstations  is  obtained  through  hardware  implementation  of  some  system  manage¬ 
ment  schemes.  Some  of  the  special  architecture  features  used  in  the  Symbolics  work¬ 
stations  includes:  tagged  architecture,  multiple  caches,  hardware  stack  pointers, 
pipelined  instruction  cycles,  and  parallel  processing  [SYMBOL88], 

b.  Software 

The  following  software  products  were  used  in  the  development  of  the 
path  planner  for  the  APS  system: 

•  Symbolics  Operating  System,  Genera  7.1,  provided  a  consistent  background 
for  the  programming  environments. 

•  The  Automated  Reasoning  Tool  (ART)  by  Inference  Corporation  is  the  princi¬ 
ple  control  language  for  the  AI  Agent.  This  rule-based,  symbolic  programming 
language  is  implemented  on  Symbolics  workstation  SYM4. 

•  Symbolics  Common  LISP  is  used  to  provide  access  to  existing  path  planning 
search  algorithms  and  communications  code. 

3.  Network 

Computer  systems  in  the  NFS  Computer  Science  Department  are  linked 
through  an  Ethernet  local  area  network  connecting  some  76  stations.  Average  day¬ 
time  traffic  is  25  packets/second  or  30%  peak  utilization  in  worst  20  second  period1. 
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Based  on  a  24-hour  lest  period  during  January  1989. 
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The  portion  of  the  network  used  by  APS  is  shown  in  Figure  2-1.  The  vehicle  simula- 
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Figure  2-1  Network  Physical  Topology 


tors  (commander  and  driver)  are  connected  directly  to  the  main  Ethernet  cable  'de¬ 
merit.  The  Symbolics  A1  workstations  are  connected  to  the  network  through  a 
mulitport  network  interconnect,  a  Digital  Equipment  DELNI.  The  How  of  communica¬ 
tions  as  seen  bv  APS  is  shown  in  Eicure  2-2. 
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in.  METHODOLOGY  AND  ASSUMPTIONS 


In  this  chapter,  different  candidate  methodologies  and  algorithms  are  explored 
and  the  rationale  behind  the  ones  chosen  discussed.  The  goal  is  to  explain  why  cer¬ 
tain  design  decisions  were  made  and  how  previous  work  was  utilized.  Small  seg¬ 
ments  of  code  or  ART  rules  are  included  to  show  the  flow  from  theory  to  application. 

A.  DEFINITIONS 

The  following  terms  are  defined  here  either  because  they  are  either  used  in  a 
non-standard  manner  or  are  key  to  the  concepts  presented  in  this  thesis. 

Slope  Angle  -  The  magnitude  (absolute  value)  of  the  angle  between  the  planar 
terrain  polygon  and  the  horizontal  plane. 

Local  Platform  -  A  platform  added  at  the  driver's  vehicle  simulator. 

Net  Platform  -  A  platform  added  at  a  remote  vehicle  simulator  and  updated 
over  the  network.  If  a  network  platform  is  selected  to  operate,  only  the  viewing 
controls  are  active.  Othe;  vehicle  parameters  are  controlled  by  its  home  simulator. 

NOGO  Terrain  -  Terrain  classified  as  having  a  trafficability  of  zero. 

Path  -  A  list  of  two  or  more  terrain  points.  The  first  point  on  the  path  is  its 
start,  the  last  point  is  its  goal. 

Terrain  Polygon  -  Planar  polygon  having  uniform  slope.  In  APS  these  are 
triangles,  one  half  of  a  terrain  grid  defined  by  the  four  elevations  at  the  v  ertices. 

Trafficability  -  The  relative  speed  at  which  a  vehicle  can  traverse  a  class  of 
terrain  due  to  roughness,  obstacle  density,  soil  conditions,  etc.  In  APS  trafficability  is 
purely  a  function  of  the  magnitude  of  the  slope  angle. 

B.  V  EHICLE  SIMULATOR 

The  vehicle  simulator  portion  of  APS  provides  for  a  realistic  depiction  of  a  tacti¬ 
cal  platform,  its  control  response,  and  its  interaction  with  tee  terrain  in  a  graphical 
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simulation  without  the  overhead  of  completely  modeling  the  full  suite  of  time  consum¬ 
ing  and  complex  physical  motion  and  dynamics. 

1.  Assumptions 

The  vehicles  and  terrain  simulated  in  this  study  are  assumed  to  have  the 
following  characteristics: 

•  Tracked  or  wheeled  tactical  vehicle  travelling  offroad,  capable  of  traversing 
60%  slope. 

•  Trafficability  of  slope  limits  vehicle  speed  before  stability  limit  is  reached. 

•  Trafficability  of  slope  limits  vehicle  speed  before  engine  power. 

•  Single  gear  ratio  modeled.  (Although  different  gears  could  be  modeled  by  lin¬ 
ing  an  array  of  time  constants). 

2.  Coordinate  Systems 

The  SGI  graphics  software  library  uses  a  three-dimensional  <3Di  graphics 
world  coordinate  system  (Figure  3-1)  in  which  the  Z  axis  represents  depth,  distance 
from  a  plane  perpendicular  to  the  eye.  rather  than  altitude  or  elevation.  Another  coor¬ 
dinate  system  is  used  when  planning  a  route  across  terrain,  corresponding  to  a  two- 
dimensional  (2D)  view  of  the  terrain  from  directly  above.  Tins  is  the  Universal  Trans¬ 
verse  Mercator  Projection.  (UTM)  coordinate  system  and  is  used  for  path  planning, 
as  in  a  military  map.  and  is  the  coordinate  system  used  for  the  terrain  database.  In 
the  UTM  system  each  point  is  represented  by  a  Grid  Zone  Designator,  a  distance 
meters  North  from  the  Grid  Zone  origin  (a  northing i.  and  a  distance  in  meters  1 
from  Grid  Zone  origin  (an  easting).  The  UTM  coordinates  of  a  point  tx.y./i  defined  m 
the  graphics  vorld  coordinate  system  can  be  found  by: 

utm_x  =  x  +  (  x_grld  *  10.0  ); 
utm_y  r  -z  ♦  (  y_grlcl  *  10.0  ); 
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Figure  3-1  Graphics  World  Coordinate  System 


3.  Platform  Rotation  Angles 

In  order  to  model  moving  objects,  a  convention  must  be  established  for  the 
rotation  of  the  body  (platform)  axes  in  relation  to  the  graphics  world  axes.  Normally 
a  platform's  direction  or  heading  is  given  as  counterclockwise  degrees  from  North. 
Weapon  systems  such  as  artillery  pieces  are  also  aimed  or  "laid"  using  an  azimuth. 
an  angle  that  follows  the  same  convention  for  direction  but  a  uses  a  different  unit  of 
angular  measure,  mils  unilliradians).  The  SGI  graphics  system  and  APS  follow  a  dif¬ 
ferent  convention.  Rotation  angles  are  measured  as  counterclockwise  angles  from  the 
positive  axis.  Thus  a  vehicle  heading  due  North  would  have  an  azimuth  (rotation 
about  the  world  Y  axis)  of  1.57  radians  or  90  degrees1.  Other  rotation  angles  follow 
normal  right-hand  rule  conventions  except  in  the  case  of  roll.  With  body  axes  as¬ 
signed  as  in  Figure  3-2,  the  following  conventions  are  established  for  APS: 

^Graphics  primitives  use  degrees  but  the  C  library  functions  use  radians.  All  angles  in  APS  are  stored  as  radians  and  converted  as 
necessary. 
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azimuth  -  Rotation  about  the  Y-axis  is  in  the  right-hand  sense,  from  the 
positive  X-axis,  Counterclockwise  as  an  observer  looks  along  the 
positive  Y-axis  toward  the  origin.  Also  called  platform’s  course  or 
orientation. 

pitch  -  Rotation  about  the  Z-axis  is  in  the  right-hand  sense,  from  the 
positive  the  X-axis,  Counterclockwise  as  an  observer  looks  along  the 
positive  Z-axis  toward  the  origin.  Angle  between  ground  (X-Z)  plane 
and  body  X-axis. 

roll  -  Rotation  about  the  X-axis  is  opposite  to  the  right-hand  sense  from 
the  positive  Z-axis.  Here  the  rotation  is  Clockwise  as  an  observer 
looks  along  the  positive  X-axis  tow-ard  the  origin, 
heading  -  Compass  course  is  a  Clockw  ise  angle  in  degrees  between 
north  (world  minus  Z-axis)  and  vehicle  X-axis.  Not  used  internally  in 
the  model,  but  it  is  used  to  display  platfo  m  azimuth  to  the  user. 


Figure  3-2  Body  vs  World  Rotation  Axes 


4.  Coordinate  System  T ransformations 

Since  the  user’s  viewpoint  is  Fixed  with  respect  to  the  vehicle  or  body  axis, 
and  the  graphics  software  requires  such  points  in  terms  of  its  own  world  unrotated  ax¬ 
is,  there  is  a  requirement  to  transform  points  between  coordinate  systems.  The  posi¬ 
tion  of  a  coordinate  in  a  rotating  coordinate  system  with  respect  to  a  Fixed  or  reference 
coordinate  system  can  be  represented  by  a  3  X  3  rotation  matrix  MRqT.  The  rotation 


angles  are  known  as  "Euler"  angles.  The  rotation  matrix  representing  rotations  about 
Euler  angles,  called  yaw  (vy),  pitch  (0),  and  roll  (0),  in  that  order  is: 

MROT  =  RZ,  roll  RY,  pitch  RX,  yaw  [F^871  PS  251  = 

cos\jrcos0  cos\jrsin0sin0  -  sin\|/cos0  cos\|/sin0cos0  +  sinysin0 
sinycos0  sin\|/sin0sin0  +  cosycos0  sin\|/sin0cosy  -  cos0sinO  (3.^ 

-sin0  cos0sin0  cos0cos0 


The  transformation  of  a  three  dimensional  vector  representing  the  body  off¬ 
set  to  the  fixed  reference  is  achieved  by  pre-multiplying1  \1R0T  by  the  vector  or: 


P  -PM 
r\V  ~  rB  v,ROT 


This  transformation  requires  the  following  operations: 

3  sin  function  calls 

3  cos  function  calls 

16  +  9  floating  point  multiplications 

4  +  6  floating  point  add/subtract 

Fortunately  the  overhead  of  these  operations  can  be  avoided  by  soiving  a 
more  general  problem  that  includes  translation  and  scaling  during  the  transformation. 
Such  a  transformation  from  body  to  world  coordinates  is  normally  done  by  means  of  a 
4X4  homogenous  transformation  matrix.  This  matrix  represents  the  location  of  a  ro¬ 
tated  and/or  translated  coordinate  system  (body),  with  respect  a  fixed  coordinate 

A  A 

system  (world).  Symbolically  then,  the  transformation  is  Pvv  =  PB  MRqj-  where 


represents  the  4  X  1  homogenous  coordinate  vector. 

The  geometry  engine  of  the  IRIS  is  designed  to  perform  these  type  of 
transformations  using  4X4  matrix  operations  efficiently.  The  world  coordinates  of 


^ Note  that  m  graphics  a  body  offset  is  transformed  to  where  it  would  appear  in  world  coordinates  so  the  rotation  matrix  is  pre-mul- 
uplied  by  the  position  vector  In  robotics  where  objects  actually  move  the  rotation  matrix  is  post  multiplied  by  the  position  vector 
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*tj> 


the  eye  position  vector,  for  example,  can  be  calculated  by  having  the  IRIS  hardware 
perform  rotations  as  if  the  body  were  an  object  about  to  be  drawn  and  pre-multiplying 
the  rotation  sub-matrix  of  the  result  by  the  offset  vector.  The  result  is  the  world  coor¬ 
dinate  offset  position.  Figure  3-3  is  an  extract  of  transform_body_to_world  that  per¬ 
forms  these  operations  using  the  IRIS  hardware. 

/*  Do  rotations  in  reverse  gimbal  order  */ 
rotate!  (Angle)(azimuth*RTOD_X_10),  *Y’ );  /*  azimuth  */ 
rotate(  (Angle)(elevation*RTOD_X_10),’Z’ );  I*  pitch  */ 
rotate!  (Angle)(-roU*RTOD_X_10),  ’X’  );  /•  roll  */ 
getmatrix(  offsetmx  );  /*  Get  accumulated  rotation  matrix  */ 

•eyex  =  dx*offset_mx[0][0]  +  dy*offset_mx[l][0]  +  dz*offset  mx[2][0); 

*eye_y  =  dx*ofTset_mx[0](l]  +  dy*offset_mx[l][l]  +  dz*offset_mx[2][l]; 

*eve_z  =  dx*offset_mx[0][2]  +  dy*ofTset_mx[l][2]  +  dz*offset_mx[2][21; 

Figure  3-3  Transforming  Body  Offsets  to  World  Coordinates 
5.  Physics  of  Motion 

Vehicle  motion  and  control  response  is  modeled  as  changes  in  the  vehicles 
velocity  vector  v,  with  changes  in  its  magnitude  being  acceleration  or  braking,  and 
changes  in  its  direction  being  steering.  The  model  treats  control  inputs  as  changes  to 
the  normal  constant  velocity  equilibrium  state  on  level  ground.  The  vehicle  engine,  at 
a  particular  throttle  setting,  provides  sufficient  force  to  overcome  all  resistance  forces 
and  maintain  a  certain  speed  corresponding  to  equilibrium  between  propelling  and 
resistance  forces.  If  the  propelling  force  is  increased  then  the  vehicle  will  accelerate 
up  to  a  new  equilibrium  velocity.  If  throttle  is  decreased  then  it  will  "coast"  down  to  a 
new'  equilibrium  velocity.  The  vehicle  velocity  corresponding  to  maximum  throttle  is  a 
program  constant,  MAX_GNDSPEED  =  45  MPH.1.  Braking  is  modeled  as 

In  APS  there  is  one  set  of  model  consumes.  All  types  of  vehicles  react  and  "feel"  the  same  to  the  driver.  A  jeep  accelerates 
no  faster  than  a  lank.  However,  these  constants  could  fairly  easily  be  expanded  to  an  array  of  constants  indexed  by  vehicle 
type 
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deceleration  at  a  variable  but  velocity  independent  rate.  Steering  response  is 
modeled  as  an  exponential  function  of  time. 
a.  Friction  and  Coasting 

A  vehicle  of  mass  m,  and  velocity  vector  "v^  travelling  on  a  level  sur¬ 
face,  has  momentum  mvt  At  equilibrium,  the  only  forces  opposing  motion  are  frictional 
resistance  forces,  FR.  Frictional  rolling  resistance  is  largely  fluid  friction  and  comes 

from  air  resistance,  lubricant  fluid  resistance  in  bearings  and  gears,  tire  deformation 
while  rotating,  soil  deformation,  etc.  For  each  resistance  force 

Fr  =  -kmvn  T?v  (3-3) 

Different  resistance  forces  have  different  exponents  for  v.  For  exam¬ 
ple,  for  air  resistance  at  low  speeds  (<  24  meters/sec),  n  =  1  [N1ARION70:  pg  53]. 
In  fact  for  all  resistance  forces  at  the  range  of  speeds  dealt  with  in  this  study,  n  <  1  is 
assumed.  For  simplicity  a  convenient  approximation  is  made  that  the  force  contribu¬ 
tion  from  all  sources  of  resistance  can  be  combined  into  one  resistance  force  with  n  = 
1,  with  some  combined  constant  k. 

Looking  at  just  at  the  magnitude  of  the  resistance  force  and  remem¬ 
bering  that  it  is  always  opposite  the  direction  of  motion,  (3-3)  becomes: 

FR  =  ma  =  mdv/dt  =  -kmv  (3-4) 

Eliminating  constant  mass  and  integrating  over  time  this  becomes: 


which  has  a  solution  of  the  form: 


J  dv/v  =  -k  J< 


In  v  =  -kt  +  C 


Using  the  initial  condition  v(t=0)  =  vq  means  C  =  In  v  .  Taking  the  exponential  of  both 


sides  gives: 


elnv  _  t-k;  +  lnvo) 
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(3-8) 


v  =  v  e  kt  (3-9) 

Let  t  =  1/k.  Then  v  =  vo  e  _la  =  vj  \/e  =  vj  2.718.  The  quantity  1/k  is  called  a  time 
constant  and  corresponds  to  the  time  it  takes  the  velocity  to  decrease  to  =  one  third  of 
its  original  value.  This  time  constant,  T,  can  therefore  be  used  to  calculate  an  average 
rate  of  change  per  unit  time  or: 

v  =  v'o"(vo  dt/t)  (3-10) 

Note  that  this  equation  depends  only  on  the  time  interval  and  velocity  at  the  begin¬ 
ning  of  the  time  interval.  It  also  avoids  calculating  the  exponential  function.  The  con¬ 
stant  T  controls  how  quickly  the  vehicle  coasts  to  a  stop  nr  lower  equilibrium  speed. 
A  large  value  of  t  corresponds  to  a  streamlined,  wheeled  vehicle  on  hard  pavement, 
as  opposed  to  a  small  value  of  t  which  might  represent  a  track  laying  vehicle  in  mud¬ 
dy  soil.  The  coasting  function  (3-10)  is  coded  as:  coast_vel  =  currvel  *  (  currvel  / 
COASTING  JTIMECONSTANT  *  elapsedsec);. 

An  analysis  of  a  typical  case  show-s  how  well  this  code  fragment  pro¬ 
duces  the  same  result  as  equation  (3-9).  For  COASTINGJTIMECONSTANT  =  10.0. 
elapsedsec  =  0.5,  and  currvel  =  40  MPH,  after  10  seconds  elapsed  time,  (3-9)  yields 
14.72  MPH  while  the  code  produces  14.34  MPH.  In  APS  the  final  velocity  for  coasting 
need  not  be  zero.  It  could  be  a  lower  equilibrium  velocity.  The  exponential  nature  of 
the  decrease  in  velocity  means  that  the  new  velocity  would  be  approached  asymptoti¬ 
cally,  never  actually  reaching  the  target  velocity  (variable  cmdvel).  Therefore  there  is 
a  cutoff  in  the  procedure  veloc!ty_model,  to  wit: 

If  ( faba(  cmdvel  •  currvel )  <  TO_MPS  )  retum(  cmdvel); 

This  returns  the  selected  velocity  as  the  current  velocity  if  it  is  already  within  I  MPH. 
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b.  Braking 

Deceleration  due  to  braking  can  be  modeled  as  a  variable  resistance 
force  that  is  independent  of  velocity.  For  a  braking  factor  b,  0.0  <  b  <  1 .0, 

FBRAKE  =  n'a  =  n'b  dv/dt  =  *BRAKE  mb  O- 1 1 > 

Eliminating  constant  mass  and  rearranging,  the  new  velocity  is  given  by: 

v  =  vo  +  dv  =  vo  +  (-*BRaKE  b  dt )  (3-12) 

or,  in  code: 

newvel  s  currvel  +  (  MAX_DECELERATION  *  brake_factor  *  elapsedsec  ); 
where  MAX_DECELERATION  is  a  constant  representing  the  maximum  rate  of  deceler¬ 
ation  before  skidding  (shear  force  between  vehicle  and  ground  >  frictional  force)  and 
brake_factor  represents  the  input  to  the  model  from  the  vehicle  controls,  a  value  of  0.0 
representing  no  braking  down  to  -1.0  or  100%  braking.  This  control  input  can  come 
from  dials,  the  mouse  or  be  calculated  by  an  autopilot. 

c.  Acceleration 

Acceleration  corresponds  to  advancing  the  throttle  position  to  a  new 
velocity  position,  vT,  causing  engine  output  to  exceed  the  propelling  force  necessary  to 

overcome  the  current  rolling  resistance.  It  assumes  linear  engine  power  output.  Sub¬ 
tracting  equilibrium  forces  at  the  current  velocity,  vo,  gives: 


=  m  dv/dt  =  k.  (  vT-v  )m 

A  r  o' 

(3-13) 

dv  =  k.(  vT .  v  )  dt 

A  T  o' 

(3-14) 

dv  =  1/t  (  vT  -  vo  )  dt 

(3-15) 

Where  X  is  again  a  time  constant  =  1  / k^.  Equation  (3-15)  is  implemented  as: 

newvel  =  currvel  +  (  (  cmdvel  -  currvel  )  *  dt  /  ACCELERATIONJIMECONSTANT; 
For  ACCELERATION_TlMECONSTANT  =  10  seconds  and  cmdvel  =  40  MPH,  this 
gives: 

0  =$  20  MPH  in  6  seconds 
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0  ^  30  MPH  in  1 1  seconds 


0  =>  40  MPH  in  21  seconds 

This  compares  well  with  the  nominal  acceleration  for  the  US  Ml  Tank  of  0  20 

MPH  in  7  seconds  [JANES 87:  pg  122], 
d.  Slope  Calculations 

Elevation  is  a  function  of  UTM  coordinates,  h(x.y).  The  gradient  of  h 
is  a  vector  in  the  ground  (X-Z)  plane  that  points  in  the  direction  of  greatest  increase 
of  altitude. 

V/j  =  dy  /  dx,  dy  /  d~  (3-16) 

This  model  is  not  so  concerned  with  the  direction  of  the  gradient  vector  as  with  its 
magnitude  and  the  magnitude  of  the  slope  angle  M>h  which  is  the  angle  between  a  tan¬ 
gent  to  the  elevation  function  and  the  X-Z  plane. 

=  tan'1  (  dy  /  dx  )~  +  (  dy  /  dz  r 

Fortunately,  it  is  not  necessary  to  calculate  the  slope  angle  directly.  It  can  be  calculat¬ 
ed  from  the  terrain  polygon  patch  surface  normal  unit  vector  N  which  is  already  avail¬ 
able  for  each  terrain  polygon  from  the  lighting  model  calculations.  Call  the  angle 

between  N  and  the  X-Z  plane,  which  is  also  the  map  ground  plane.  Since  N,  with 
components  xN,  vv  zv  is  perpendicular  to  the  terrain  polygon,  I  I  +  I  I  =  K  / 

2.  Now  =  tan'1  (  yN  !  (  xN  +  zN  )'1/2  ),  and  since  tan(  n  /  2  --  9  )  =  cot(  0  )  and 
tan(  0  )  =  1  /  cot(  0  ),  then 

\ih  =  tan'1  ( (  xN  +  zN  )'1/2 /yN  )  (3-18) 


(3-17) 
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In  the  vehicle  simulator,  this  result  is  produced  by  the  function 
convert_normal_to_slope  which  returns  \\th  in  radians. 

If  the  surface  normal  of  the  terrain  polygon  is  not  readily  available 
(perhaps  because  vertex  normals  are  being  used),  the  effective  slope  of  the  vehicle 
can  be  calculated  from  its  pitch  and  roll.  These  body  angles  are  used  to  calculate  the 
world  coordinates  of  a  body  normal,  a  normal  vector  which  points  out  the  roof  of  the 
vehicle,  using  another  math  function  transform_body_to_world,  shown  in  Figure  3-4. 

float  normal[3],  slope; 

transform_body_to_wor!d(  platform->cse, 

platform->base_pltch, 

platform->base_roll, 

0.0, 1.0,  0.0, 

&norma![0], 

&normal[l], 

&nomnal[2] ); 

slope  =  convert_normal_to_slope(  normal ); 


Figure  3-4  Calculating  Effective  Slope  Using  Platform  Orientation 

Finally,  vehicle  pitch  alone  can  be  used  as  effective  slope  to  limit 
speed,  since,  stability  factors  aside,  pitch  angle  is  the  slope  resistance  the  engine 
must  overcome. 

e.  Effects  of  Slope 

Instead  of  directly  modeling  the  effect  of  acceleration  forces  on  a  vehi¬ 
cle  due  to  gravity  when  travelling  on  sloping  terrain,  the  model  assumes  that  the  traf- 
ficability  of  sloping  terrain  limits  vehicle  speed  before  engine  power  would  be 
insufficient  to  maintain  a  set  speed.  Maximum  vehicle  speed  is  limited  by  a  slope 
governor  that  decreases  maximum  speed  as  a  function  of  slope.  This  slope  governor 
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function  is  shown  in  Figure  3-5  where  MAX_GNDSPEED  is  the  maximum  speed  a 


Figure  3-5  Slope  Governor  Function 


vehicle  can  achieve  on  level  ground  and  MAXSLOPE  (27°)  is  the  maximum  slope  tra¬ 
versable  by  the  vehicle.  Since  limited  speed  could  go  to  zero  in  untrafficable  terrain, 
the  vehicle  would  be  stuck,  unmovable,  if  it  ever  entered  a  NOGO  terrain  patch.  A 
low  "maneuver"  speed  is  allowed  for  the  driver  to  carefully  and  slowly  work  his  way 
out  of  such  a  situation. 

/.  Suspension  Oscillation  -  “ Bounce ” 

When  a  vehicle  crosses  a  Dump  or  other  change  in  terrain  sivpe.  n 
induces  an  oscillation  in  the  spring-mass  suspension  system.  This  oscillation 
continues  until  it  is  damped  by  the  shock  absorbers  and  friction  of  the  vehicle 
suspension  moving  parts.  This  motion  can  be  quite  difficult  to  model  due  to  the 
complex  geometry  of  a  vehicle  suspension  system.  However,  by  limiting  oscillations 
to  changes  in  vehicle  pitch  angle  only,  this  motion  is  easily  modeled  as  simple 
damped  harmonic  oscillation  along  a  single  axis  (the  vehicle  pitch  angle)  as  shown  in 
Figure  3-6.  This  transient  pitch  is  then  added  to  the  base  vehicle  pitch  caused  by  the 


slope  of  the  terrain.  Two  additional  fields  in  the  vehicle  data  structure  are  created  to 
handle  this  effect,  bounce_amplHude  and  bouncejime. 


The  equation  for  damped  harmonic  motion  [MARION70  :pg  37 1 J  is: 

y  =  y0  cost  toDt  +  8  )  (3-19) 

II  II 

amplitude  oscillation 

where  P  =  b  /  2m,  b  is  the  damping  force,  m  is  the  mass  of  the  vehicle,  and  a>0  is  the 
frequency  of  undamped  oscillations  of  the  system.  Assume  coD  =  coo.  Choose  a  time 
constant  t,  which  is  equal  to  the  time  interval  when  amplitude  of  the  oscillations  has 
decreased  to  1  /  e  of  its  original  value,  which  is  x  =  2 m  /  b.  Equation  (3-19)  can  then 
be  written  as: 

y =  [  yc~ f  y0  *<*/t )]  *  cos(wDt)  (3-20) 

If  the  displacement  y  is  the  suspension  travel  at  the  front  wheels  then  0  = 
tan_1(  y  /  wheelbase).  For  relatively  small  displacements,  the  damped  harmonic  oscil¬ 
lations  can  be  calculated  directly  using  the  pitch  angle  9  and  (3-20)  becomes: 
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9  =  [  0O  -  (  0o  *  dt  /  x  )]  *  cos(  coDt )  ( 3-2 1 ) 

This  can  be  broken  up  into  two  code  steps  for  each  cycle  of  the  update  loop: 

1)  Calculate  the  current  angular  oscillation  value. 

bounce_pitch  =  bounce_amplitude  * 

cos(  OSCILLATION_FREQUENCY  *  TWOPI  *  totaljime  ); 

2)  Calculate  new  bounce  amplitude  based  on  damping  effect. 

bounce_amplltude  =  bounce_ampiltude  - 

(  bounce_amplltude  *  dt  /  DAMPING_TIMECONSTANT  ); 

With  DAMPING_TIMECONSTANT  set  to  (  1  -  Me  )  / 1. 

Empirically,  equation  (3-21)  and  its  code  can  be  shown  to  approxi¬ 
mate  the  results  of  (3-19).  Considering  a  typical  case1  and  comparing  just  the  de¬ 
cline  in  amplitude  after  3.0  seconds,  equation  (3-21)  yields  5  5°  (convened  from  v 
displacement),  while  the  code  gives  4.8°.  Only  a  small  pan  of  this  difference  (app 
0.1°)  comes  from  osc.  tting  the  pitch  angle  directly  instead  of  oscillating  the  displace¬ 
ment  and  then  convening,  5.5°  versus  5.6°.  The  total  error  is  small  enough  that 
"tuning”  the  constants  can  bound  this  error  well  within  the  difference  detectable  in  a 
moving  visual  simulation. 

6.  Simulation  Time  Interval 

The  model  time  interval,  or  dt,  using  Leibnitz  notation,  is  the  elapsed  time 
required  to  complete  one  processing  loop  in  simulation  time.  Since  the  rates  of 
change  of  most  of  the  processes  are  non-linear,  the  linear  approximation  used  is  only 
a  good  approximation  if  dt  is  small,  «  1  second.  The  second  problem  that  results  if  dt 
is  not  small  enough  comes  from  delayed  control  feedback.  For  example,  if  steering  a 
vehicle  in  a  turn  and  dt  is  of  the  order  of  1  second  then  the  driver  will  tend  to  over¬ 
shoot  control  corrections,  making  it  difficult  to  steer  onto  a  desired  course  or  avoid  ob¬ 
stacles.  This  lower  bound  is  due  to  control  response  and  depends  on  many  factors, 

f*or  DAM  PIN  G_CO  N  S  I  ANT  ~  3  0,  dt  =  0  25  seconds,  wheelhasc  =  2  0  meters,  initial  displacement  of  5  meter*  ~  15  degrees,  and 
tola!  time  =  30  seconds 
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including  platform  velocity,  control  responsiveness,  complexity  of  maneuvers,  etc.  Re¬ 
sponsiveness  for  an  aircraft  travelling  at  hundreds  of  MPH  must  be  greater  than  for  a 
ground  tactical  vehicle  travelling  cross  country  at  speeds  typically  <  25  MPH.  For 
such  ground  vehicles,  a  subjective  lower  bound  appears  to  be  3-4  frames  or  cycles  per 
second. 

7,  Paths 

Paths  in  APS  resemble  the  military  concept  of  a  "route"  with  an  SP  (Start 
Point),  RP  (Release  Point)  or  goal,  and  a  CP  (Check  Point)  at  turning  points  or  criti¬ 
cal  points.  Figure  3-7  shows  the  path  data  structure.  The  SP  of  the  path  is  its  first 
point  and  the  RP  is  the  last  point  on  the  path.  Each  platform  data  structure 
(Appendix  A)  contains  a  pointer  to  a  path  and  a  pointer  to  the  next  point  along  the 
path.  Path  manipulation  routines  are  contained  in  module  path.c. 

Paths  are  created  and  maintained  separately  from  platforms.  When  a  vehi¬ 
cle  is  "assigned"  a  path  to  traverse,  a  copy  of  the  path  is  made  for  the  platform  and  a 
pointer  to  the  platform  is  added  to  the  list  of  platforms  assigned  to  that  path.  Thus 
several  platforms  can  be  assigned  to  traverse  a  path  and  navigate  along  it  indepen¬ 
dently.  Also,  if  a  point  on  the  original  path  is  altered,  all  affected  platforms  can  be  no¬ 
tified.  On  the  other  hand,  if  a  platform  must  deviate  from  the  path  to  avoid  an 
obstacle,  intermediate  points  can  be  inserted  in  the  platform’s  copy  of  the  path  with¬ 
out  affecting  the  original. 
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Figure  3-7  Path  Format 

A  platform  being  guided  by  an  external  agent  by  receiving  one  point  at  a 
time  is  actually  following  a  path  that  consists  solely  of  a  periodically  updated  goal. 
As  new  guide  points  are  received,  the  goal  point  is  replaced.  The  autopilot  module 
can  then  navigate  a  platform  along  a  path  by  heading  successively  toward  each  point 
on  the  path  list.  Figure  3-8  shows  a  tank  approaching  the  goal  point,  which  is  drawn 
as  a  tall,  pyTamid  marker  on  the  terrain.  The  paths  are  maintained  as  a  linked  list 
managed  using  four  global  variables: 

pathlist  -  pointer  to  first  path  on  path  list, 
pathllsland  -  pointer  to  last  path  on  path  list. 
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Figure  3-8  Driving  a  Tank  Toward  Its  Goal 


32 


numpaths  -  number  of  paths  currently  on  pathlist. 

path_pickid  -  unique  identifier  for  graphics  picking. 

Path  manipulation  is  accomplished  by  selecting  the  "PATH  OPERA¬ 
TIONS"  entry  in  the  main  menu.  The  path  operations  menu  is  then  constructed  and 
displayed,  providing  for  the  selection  of  up  to  four  functions: 

1  -  Display  Paths  -  ON/OFF 

2  -  Construct  a  Path 

3  -  Delete  a  Path 

4  -  Assign  Vehicle  to  a  Path 

The  first  option  toggles  the  display  of  paths  on  the  2D  terrain  map.  Figure  3-9  shows 
the  display  used  to  manipulate  paths.  Paths  are  displayed  by  default  but  may  be 
turned  off  to  reduce  screen  clutter.  Menu  option  3  is  only  presented  if  there  is  at  least 
one  path  defined.  Option  4  is  only  presented  under  the  additional  condition  that  at 
least  one  platform  is  defined.  At  present,  all  platforms  except  FOGM  can  be  as¬ 
signed  to  a  path.  A  path,  once  defined,  is  stored  in  a  file  containing  all  currently  de¬ 
fined  paths.  When  APS  is  started,  it  searches  for  a  file  "aps_paths.dat"  in  the 
following  directories,  in  order:  the  current  (default)  directory,  the  directory  containing 
the  APS  executable,  and  the  "DTED"  directory.  If  the  file  is  found.  APS  loads  the 
paths  it  contains.  Each  time  a  path  on  the  path  list  is  created  or  destroyed,  the  file  is 
updated. 

8.  Guidance  States 

The  current  control  state  of  each  platform  is  reflected  by  the  combination  of 
two  fields  in  each  platform  record: 

control  -  MANUAL  or  AUTOPILOT 

ext_guidance  -  ON  or  OFF 

The  slot  ext_guidance  determines  whether  platform  guide  points  are  taken  from  in¬ 
coming  message  or  an  assigned  path.  The  slot  control  determines  whether  course 


commands  are  calculated  by  the  autopilot  or  are  provided  from  the  vehicle  controls 
(dials  or  the  mouse  joystick). 


9.  Autopilot 

The  autopilot  determines  the  commanded  course  and  speed  for  each  local 
platform  that  has  its  control  field  set  to  AUTOPILOT  and  has  a  path  defined.  Since 
external  guidance  messages  update  the  platform’s  local  path  record,  the  autopilot 
functions  irrespective  of  the  source  of  the  path  data.  The  autopilot  calculates  an  azi¬ 
muth  to  the  current  guide  point.  The  current  guide  point  is  automatically  updated  to 
its  successor  on  the  path  (if  there  is  one)  when  the  platform  is  within  VICINITY 
meters  of  the  way  point.  If  the  platform  gets  within  ARRIVED_DISTANCE  of  the 
guide  point  then  the  guide  point  must  be  the  last  point  on  the  path,  i.e.  the  path  goal. 
If  so  then  the  autopilot  applies  the  brakes  to  bring  the  platform  to  a  halt  without  over¬ 
running  the  goal.  Figure  3-10  shows  the  relationship  of  these  distances.  Precise 


VICINITY 

ARRIVED 

DISTANCE 


Figure  3-10  Autopilot  Control 


control  would  require  both  these  distances  be  variables  that  are  a  function  of  the  plat¬ 
form’s  speed,  instead  of  constants,  so  that  a  platform  starts  to  brake  or  turn  in  the 
time  necessary  to  stop  or  turn  exactly  over  the  guide  point.  This  level  of  precision 
would  be  necessary  to  navigate  a  platform  through  a  field  of  obstacles  and  would  re¬ 
quire  projecting  ahead  the  platform’s  location  so  as  to  issue  the  proper  commands  at 
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the  correct  time.  However,  the  simpler  algorithm  presently  used  is  adequate  to  halt  a 
platform  travelling  at  maximum  ground  speed  (MAX_GNDSPEED)  before  reaching 
the  goal. 

B.  PATH  PLANNING 
1.  Introduction 

The  path  planning  process  for  this  study  simulates  the  actions  of  the  vehi¬ 
cle  commander  in  planning  paths,  and  issuing  waypoints  for  a  controlled  vehicle.  The 
commander  starts  out  with  the  following  facts: 

•  Which  vehicle  is  being  controlled. 

•  Start  point  and  goal  locations  are  known. 

•  A  terrain  map  of  the  region  to  be  traversed  is  available. 

•  The  terrain  map  contains  cost  of  traversal  information  for  the  region. 

•  Vehicle  speed. 

•  Vehicle  course. 

•  Vehicle  guidance  mode. 

•  Vehicle  location  in  UTM  coordinates. 

•  Current  simulation  time. 

The  commander  uses  this  information  to  plan  a  path  to  the  goal,  selecting 
the  quickest  path  between  the  start  point  and  the  goal  point.  In  selecting  a  path,  the 
commander  chooses  prominent  terrain  features  as  guiding  waypoints  for  the  driver. 
Once  the  path  is  selected,  the  commander  issues  commands  to  the  driver  to  proceed 
to  the  first  waypoint  as  indicated  by  the  commander.  The  commander  continues  to  is¬ 
sue  new  waypoints  as  the  driver  pilots  the  vehicle  close  to  the  last  waypoint.  As  the 
simulation  continues,  the  commander  needs  to  be  informed  of  changes  to  the  vehicles 
status  as  indicated  here. 

•  Vehicle  ID. 

•  Vehicle  speed. 

•  Vehicle  course. 

•  Vehicle  guidance  mode. 
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•  Vehicle  location  in  UTM  coordinates. 

•  Current  waypoint  location  in  UTM  coordinates. 

2.  Path  Planner  Control  Program 

The  path  planning  simulation  of  the  commander  is  divided  into  two  major 
areas,  the  overall  controlling  program  and  the  actual  search  algorithm  that  does  the 
path  planning.  The  term  path  planner  is  used  to  describe  the  combined  AI  processes 
that  make  up  the  AI  simulation  of  the  path  planning  commander.  The  path  planner  is 
kept  separate  from  the  graphics  simulation  of  the  vehicle  and  implemented  on  the 
Symbolics  AI  workstations.  Two  reasons  for  this  are:  first,  a  great  deal  of  path  plan¬ 
ning  work  done  at  the  Naval  Postgraduate  School  is  done  using  AI  workstations,  and 
second,  a  substantial  amount  of  the  program  code  produced  is  done  in  LISP  and  Pro¬ 
log  that  can  be  easily  ported  between  the  different  AI  workstations. 

The  path  planner  control  program  is  separated  from  the  actual  search  por¬ 
tion  of  the  path  planner  for  three  reasons.  The  first  is  to  allow  modularization  of  the 
code.  The  communication  costs  associated  with  this  approach  do  not  appear  to  over¬ 
ride  the  benefits  of  being  able  to  substitute  different  search  algorithms.  The  second 
reason  for  the  separation  was  to  allow  the  path  planner  control  program  the  exclusive 
use  of  a  workstation.  Expert  system  shells  require  considerable  system  resources, 
and  it  is  felt  that  the  overhead  of  running  the  expert  system  shell  would  put  an  exces¬ 
sive  load  on  a  single  workstation  when  combined  with  running  real  time  path  planning 
searches.  Finally,  this  separation  should  allow  more  than  one  search  program  to 
work  simultaneously. 

cl  The  Expert  System  Shell 

High  turnover  and  short  learning  curves  predominate  much  of  the  frus¬ 
tration  associated  with  thesis  work.  Therefore,  since  one  of  the  major  goals  in  this 
study  was  to  provide  a  test  platform  that  could  be  used  to  study  the  relationships  as¬ 
sociated  with  the  application  of  artificial  intelligence  techniques  to  the  control  of  au¬ 
tonomous  vehicles,  it  would  be  advantageous  to  have  the  path  planner  controller 
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written  in  a  high  level  symbolic  programming  language.  The  use  of  such  a  language  al¬ 
lows  a  researcher  to  examine  problems  at  a  much  higher  level  of  abstraction  than  with 
LISP  or  Prolog. 

One  of  the  criteria  in  the  selection  of  an  expert  system  shell  was  the 
desire  to  have  the  path  planner  control  program  continuously  monitor  the  knowledge 
database  and  react  to  changes  therein.  Forward  chaining  control  strategies  facilitate 
tms  continuous  now  within  the  iuic  based  sysiem  by  simply  keeping  fresh  facts  as¬ 
serted.  In  ART  and  KEE,  the  forward  chaining  mechanism  is  self  contained  in  the  in¬ 
ference  engine  of  the  shell.  There  are  forward  chaining  control  implementations 
written  for  both  LISP  [MCNKLE&88]  and  Prolog  [ROWE88],  but  abstracting  the  re¬ 
searcher  away  from  the  mechanics  of  forward  chaining  produces  code  which  is  easier 
to  understand. 

ART  w-as  chosen  over  KEE  in  part  because  it  appeared  easier  to  ex¬ 
amine  the  workings  of  the  rules  in  ART.  ART  allows  direct  manipulation  of  the  rules 
through  Symbolics’  ZMACS  editor,  and  through  the  use  of  ART’s  ability  to  watch  and 
record  the  Firing  of  rules,  and  the  assertion  and  retraction  of  facts. 
b.  How  ART  Works  as  a  Process  Controller 

ART  is  a  rule-based,  expert  system  shell,  containing  the  ability  to 
forward  chain  and  backward  chain.  The  principle  inference  engine  is  the  forward  chain- 
er.  As  stated  in  Chapter  II,  an  ideal  inference  engine  within  a  shell  would  provide  an 
uncluttered  view  of  the  rules  and  knowledge  base  used  in  a  problem.  In  reality,  there 
are  inherent  limits  on  the  inference  engine  implemented  within  ART.  One  important 
limit  is  that  an  artificial  structure  and  order  are  imposed  on  rule  firing.  A  simple  exam¬ 
ple  of  this  is  the  difference  between  the  Firing  of  two  rules  that  require  identical  pre¬ 
conditions.  One  rule  must  fire  first.  The  engine  must  decide.  The  choice  could  be  as 
simple  as  choose  the  rule  that  appears  first  in  the  program  structure,  or  choose  the 
shortest  rule.  And  though  the  choice  may  be  arbitrary  it  must  be  consistent.  ART  ap¬ 
pears  to  choose  the  first  rule  in  the  program  structure. 
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(1)  Rule  Structure.  ART’s  rule  structure  provides  a  straightforward 
way  of  declaring  the  complete  predicate  logic  for  a  given  rule.  A  sample  rule  extracted 
from  the  path  planner  control  program  is  presented  in  Figure  3-11  below.  The  left  side 
of  the  rule  contains  the  preconditions  necessary  for  the  rule  to  Fire.  The  right  side  of  the 
rule  carries  out  actions.  These  actions  can  be  controlled  by  binding  temporary  facts  and 
by  examining  states  through  the  use  of  conditional  statements.  The  parts  of  the  rule 
are  clearly  shown  in  Figure  3-11.  Here  the  rule  is  fired  when  the  fact  (menu  one)  is 
asserted.  The  right  side  of  the  rule  can  request  the  operator  to  perform  some  action 


(defrule  MENU1 
(schema  sym 

(one  ’si) 

(two  ’s2) 

(three  ’s3)) 

?a  <-  (m6nu  one) 

s> 

(printout  1 1  "Where  is  the  path  planner  located ’") 

(printout  1 1  "Your  choices  are  the  following,  chose  one  by  it's  letter.  * 
t "a "  ’si 
t "b "  ’s2 
t "c "  ’s3 

t  "NOTE— Please  ensure  that  the  path  planning  software  is  running" 
t) 

(bind  ’b  (read)) 

(if  (or  (eq  ’b  a) 

(eq’B'A)) 

then 

(assert  (sym-lmk  ?s  1 ) 

(menu  two) 

else 

(retract  ’a) 

(assert  (menu  one))  ) ) 

) 

(retract  ’a) 

) 

Figure  3-11  MENU1  Code  Fragment 


such  as  choose  the  Symbolics  machine  where  the  search  control  program  resides.  The 
operator’s  response  is  then  checked  to  ensure  a  valid  response,  and  facts  are  asserted 
that  enable  the  Symbolics  communications  start  up  rule  to  fire  and  start 


communications  with  the  appropriate  Symbolics  workstation.  Of  special  note  here  is 
that  a  fact  in  ART  must  be  retracted  before  it  is  reasserted.  If  the  fact  is  asserted 
before  it  is  retracted,  the  assertion  will  be  lost.  Thi*  is  because  ART  keeps  only  one 
copy  of  identical  facts.  The  Path  Planner  Control  Program  contained  in  Appendix  B 
provides  a  more  detailed  look  at  the  code. 

(2)  Continuous  Forward  Chaining.  A  rule  Firing  control  mechanism  is 
needed  mat  allows  the  path  planner  control  program  to  continuously  monitor  the 
knowledge  base  and  the  communications  sub-process.  This  is  accomplished  with 
continuous  forward  chaining  by  cycling  through  a  base  set  of  rules.  The  rules  chosen 
for  this  cycling  are  the  interface  with  the  vehicle  clock  and  the  calls  to  the  system’s 
communications  pons.  These  rules  are  selected  because  they  are  the  most  likely 
routes  for  new  facts  to  enter  the  knowledge  base  of  the  commander.  The  Symbolics 
read-char-no-hang  stream  read  method  is  used  in  the  communications  rules  to  ensure 
that  the  communications  calls  do  not  wait  if  there  is  no  data  on  the  lines.  Rule  cycling 
begins  when  a  rule  has  met  all  of  its  enabling  preconditions.  A  rule  fires  when  all  of 
its  enabling  facts  are  met.  The  rule  check-comm-links-lrls  retracts  its  enabling  fact, 
and  asserts  the  facts  (check-comm  iris),  (check-comm  sym),  and  (clock-update  yes). 
Order  of  assertion  is  important  here  because  the  last  fact  asserted  will  be  pursued 
first,  as  explained  in  Paragraph  c.  below.  If  no  information  is  available  from  the  IRIS 
communications  link,  the  clock  is  updated,  the  Symbolics’  communications  link  is 
checked,  and  finally  ART  cycles  back  through  the  checking  of  the  IRIS 
communications  link. 

(3)  Rule  Precedence.  Actions  by  a  human  commander  are  taken 
according  to  some  precedence  or  order  imposed  by  the  commander’s  judgement.  It  is 
desired  to  duplicate  the  human’s  ability  to  judge  and  separate  actions  that  need  to 
happen  immediately  from  those  that  could  be  postponed.  Assigning  rules  an  order-  of 
precedence  allows  more  important  rules  to  be  examined  first.  Rule  precedence  is 
accomplished  by  the  use  of  ART’s  salience  function.  Salience  values  are  from  -10000 
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(lowest  precedence)  to  10000  (highest  precedence).  A  rules  salience  value  is 
assigned  at  compile  time.  If  the  rule’s  salience  is  not  declared,  a  value  of  0  is 
assigned.  Rules  of  the  same  salience  are  loaded  onto  a  stack  as  they  become  ready  to 
fire.  Rules  thus  grouped  are  fired  according  to  their  salience  value  first,  then 
according  to  their  position  on  the  stack.  It  is  useful  to  think  of  ART  as  having  a 
separate  stack  for  each  salience  value,  and  always  firing  rules  off  the  stake  with  the 
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is  fired  first.  This  provides  a  mechanism  to  mimic  the  human  ability  to  pursue  w-hat 
should  be  done  first.  Rules  must  be  written  such  that  more  important  things  have 
higher  saliences  than  less  important  things.  The  consequences  of  this  stack  action 
effectively  imposes  a  most  recent  fact  following  algorithm.  A  side  effect  of  a  most 
recent  fact  following  algorithm  is  that  it  can  lead  to  indefinite  postponement  of  rules. 
This  can  happen  in  two  different  ways.  First,  if  high  precedence  rules  are  continually 
added  to  the  agenda  stacks,  low  precedence  rules  will  never  fire.  A  second  and  more 

subtle  way  a  rule  couiu  be  ir^finitely  postponed  is  by  asserting  a  fact  that  activate* 

a  rule  of  the  same  precedence  as  the  postponed  rule.  Since  all  newly  asserted  rules 

are  loaded  to  a  stack,  the  most  recent  rule  is  looked  at  first,  thus  postponing  the  older 

rule.  This  indefinite  postponement  is  easily  handled  in  Prolog  by  using  an  assertz 
command.  Using  ART,  the  programmer  must  control  rule  firing  by  sequentially 
activating  rules,  and  ensuring  that  all  sequences  of  rule  firings  lead  back  to  the  lowest 
level. 


(4)  LISP  Calls.  LISP  calls  are  used  where  it  is  more  convenient  to 
perform  an  action  on  LISP  data  structures  or  to  use  existing  LISP  functions.  LISP 
calls  can  be  made  only  on  the  right  hand  side  of  rules,  and  are  delineated  by  #L 
immediately  before  the  LISP  code.  ART  can  make  direct  use  of  LISP  symbols  and 
values,  but  is  clumsy  at  manipulating  LISP  lists.  Therefore,  LISP  lists  are  converted 
to  ART  facts  and  schemas  that  use  relations  within  ART  to  link  related  facts.  An 
example  of  this,  in  Appendix  B,  is  the  rule  process-waypoints.  In  this  rule,  the 
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incoming  waypoints  are  stored  with  the  vehicle  and  their  sequence  number  from  the 
list  they  came  from.  ART  also  fails  to  recognize  the  strings  produced  by  calls  to 
LISP  communications  packages.  Here  Common  LISP  provides  the  Intern  function  to 
convert  a  string  into  a  symbol.  This  symbol  is  then  fed  to  ART.  As  can  be  seen  in 
Figure  3-12  below,  the  intern  command  requires  a  prefix  that  designates  which 
Symbolics  package  the  LISP  function  is  defined  in.  The  ART  package  does  not  have 
all  of  the  Symbolic'-’  Common  LISP  functions  available. 

(bind  ?b  ,*L(sd:intem  (sctsend  talk-i  check-iris  3))) 

(it  (eq  ?b  '>»)  then 


Figure  3-12  Code  Excerpt  from  the  Rule  read-update 

3.  Path  Planning  and  Search  Algorithms 

The  second  portion  of  the  path  planner  is  the  search  algorithm.  The  require¬ 
ments  for  the  algorithm  are  that  it  accept  as  input  the  following  data: 

•  Start  point 

•  Goal  point 

•  Vehicle  ID 

•  UTM  coordinates  of  the  lower  left  hand  comer  of  the  10  KM  grid  window. 

The  output  requirements  are  waypoints  passed  individually  with  the  con v.  ponding 

sequence  number  and  vehicle  ID. 

a.  Search  Region  Representation 

Planning  a  path  across  real  or  simulated  terrain  requires  some  criteri¬ 
on  be  established  that  will  allow  the  path  planner  to  choose  between  routes.  Slope  is 
a  common  terrain  feature  used  as  a  simple  distinguishing  factor  [ROWE&88].  The 
greater  the  slope,  the  greater  the  cost  of  traversal.  This  criterion  has  some  interesting 
properties  that  are  not  in  accord  with  the  physical  environment.  In  APS,  effective 
slope  is  an  absolute  value  independent  of  the  direction  of  traversal.  In  traversing  an 
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actual  physical  region  a  given  incline  has  varying  degrees  of  relative  slope  depending 
on  the  traversal  angle.  Since  the  major  goal  in  this  study  is  to  build  a  test  platform 
that  would  allow  the  testing  of  search  algorithms  and  their  interfaces  with  simulated 
vehicles,  this  discrepancy  is  accepted  in  the  interest  of  simplifying  the  problem.  An  in¬ 
teresting  result  of  this  simplification  is  that  bidirectional  searches  can  be  performed, 
because  the  cost  of  traversal  is  independent  of  the  direction  of  travel  across  a  given 
legion  *vitn  a  given  slope. 

Discrete  geometric  cells  were  used  because  of  the  simplicity  of 
conversion  from  the  graphics  elevation  data  to  the  slope  data  used  by  the  wavefront 
path  planner.  The  use  of  the  wavefront  search  techninue  was  based  on  the 
construction  of  the  elevation  and  slope  data  files  and  the  ease  of  implementation  of 
the  wavefront  algorithm.  The  slope  data  files  produced  by  Felhoelter's  methods  were 
designed  to  contain  all  of  the  information  about  a  given  search  region  [FELHOE88], 
This  information  included  the  boundary'  information  that  ensured  the  search  algorithm 
would  not  overflow  the  search  region.  This  boundary'  information  was  otherwise 
unrelated  to  slope  information  of  the  region.  The  stripping  off  of  this  boundary 
information  was  trivial  and  could  be  accomplished  while  building  the  slope  files  or 
after  they  were  complete.  However  it  became  apparent  that  the  use  of  slope  data 
files  containing  one  by  one  to  ten  by  ten  kilometers  of  slope  data  would  prove  difficult. 
Using  files  built  in  this  manner  would  have  required  the  use  of  1225  to  625  separate 
slope  data  files  for  a  35  KM  by  35  KM  map  that  covered  the  same  region  as  the  map 
used  by  the  IRIS  based  vehicle  simulator.  It  would  have  also  required  either 
predefining  the  area  to  be  searched  or  some  other  way  of  selecting  the  appropriate  file 
for  a  given  run.  Initially  a  35  KM  by  35  KM  slope  data  file  w’as  used,  but  it  was  found 
that  the  time  to  read  in  the  data  took  as  long  as  six  minutes.  This  long  read-in  time 
occurred  because  each  record  of  the  file  had  to  be  read  in  sequentially  until  all  of  the 
data  for  a  given  map  was  read  in.  This  read-in  time  was  reduced  to  one  minute  by 
converting  the  text  file  to  a  binary  tile  and  using  the  Symbolics  LISP  file-position 
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function,  which  is  Symbolics’  equivalent  to  the  Iseek  function  of  C.  Finally,  the  slope 
files  were  recomputed  using  the  graphical  methods  developed  on  the  IRIS 
workstations.  This  was  done  because  the  methods  used  by  Felhoelter  produced 
significandy  different  slope  data  than  that  produced  on  the  IRIS  workstations.  This 
difference  appears  to  be  based  on  the  fact  that  the  vehicle  simulator  uses  the  slope 
calculated  from  the  lower  left  triangle  of  a  one  hundred  meter  square  in  the  graphics 
simulation.  These  triangles  were  used  because  they  form  the  planar  surfaces  used  in 
the  graphical  displays  on  the  IRIS  workstations,  and  the  drawing  routines  provide 
normals  to  the  surface  from  which  slope  can  be  easily  calculated.  These  methods 
were  described  earlier  in  this  chapter.  The  only  significant  difference  between  the  v.vo 
methods  is  when  the  slope  calculations  are  performed.  The  slope  information  for  the 
Symbolics  processes  is  calculated  before  the  simulation  is  begun,  while  the  slope 
information  is  produced  at  system  run-time  by  the  vehicle  simulator. 

C.  AUTONOMO!  S  vs.  MANUAL  CONTROL 

The  guidance  and  control  states  of  APS  have  been  previously  described.  What 
follows  contains  a  fuller  explanation  of  what  is  involved  in  the  transition  between 
these  siates.  The  states  were  designed  to  be  as  independent  and  flexible  as  possi¬ 
ble,  to  allow  switching  in  and  out  of  autopilot  control  while  being  guided  by  an  exter¬ 
nal  agent  and.  conversely,  to  allow  switching  external  guidance  on  and  off  while 
remaining  under  autopilot  or  manual  control.  Ideally,  the  source  of  external  guidance, 
human  or  AI  agent,  would  be  transparent  to  the  guidance  system.  Unfortunately,  the 
methodology  used  for  human  control  introduced  asymmetries  into  the  design.  An  ex¬ 
ternally  guided  vehicle  is  controlled  by  a  remote  human  path  planner  on  another  graph¬ 
ics  workstation  differently  than  it  is  guided  by  the  remote  AI  agent.  The  human 
commander  designates  a  path  for  a  remote  platform  vehicle  just  as  if  it  were  a  local 
platform.  The  path  is  then  transmitted  across  the  network  in  its  entirety.  Thereafter 
the  vehicle  driver  navigates  as  if  the  path  had  been  generated  locally.  On  the  other 


44 


hand,  the  AI  agent  transmits  one  path  point  (guide  point)  at  a  time,  successively  up¬ 
dating  them  as  the  vehicle  gets  near.  The  source  of  this  lack  of  symmetry  lies  in  the 
greater  functionality  of  the  AI  agent.  It  was  designed  to  calculate  a  new  path  if  the 
controlled  vehicle  encountered  unforeseen  obstacles  or  deviated  too  far  from  the  calcu¬ 
lated  path.  This  cannot  be  done  in  advance.  This  dual  role  of  global  and  local  planner 
was  never  envisioned  for  the  remote  human  commander  except  in  the  case  of  replac¬ 
ing  one  global  path  with  a  new  one.  In  essence  then,  the  external  guidance  state  be¬ 
comes  one  of  exclusive  AI  agent  control  and  the  methods  used  for  the  transitions 
back  and  forth  between  external  and  internal  guidance  are  designed  to  accommodate 
the  different  models  of  guidance  and  preserve  the  transparency  to  the  rest  of  the  vehi¬ 
cle  simulator. 

A  platform’s  external  guidance  can  be  toggled  ON  or  OFF  either  locally  by  a 
popup  menu  selection  from  the  driving  menu  or  remotely  by  network  message.  This 
network  message  is  generated  by  a  remote  human  commander  making  the  same 
menu  selection  as  would  the  local  operator.  If  the  selection  is  made  locally,  the  mode 
transition  is  made.  If  the  selection  is  made  remotely,  the  message  is  transmitted. 
Actions  on  the  local  platform  are  the  same  regardless  of  the  source  of  the  command. 
At  present,  no  authentication  or  permission  system  is  used,  nor  is  there  a  leva!  look¬ 
out  or  override  provided. 

External  Guidance  OFF  -->  ON  causes  the  follow  ing  actions: 

1 )  Set  ext_guidance  toggle  ON. 

2)  Send  an  INITIALIZE  control  message  to  the  AI  agent  containing  the  UTM 
coordinates  in  meters  of  the  origin  of  the  current  ten  kilometer  box,  vehicle  identifier, 
start  and  goal  points  of  the  path,  and  current  simulation  time  (If  no  AI  agent  is  con¬ 
nected  the  message  is  discarded).  Note  that  the  start  point  sent  is  tne  platform’s 
current  guide  point  which  may  not  be  the  SP  of  the  originally  assigned  path.  If  the 
platform  had  partially  navigated  a  path  under  internal  guidance,  then  the  guide  point 
will  be  the  next  point  in  the  remainder  of  the  path. 
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3)  Set  up  the  platform  to  receive  guide  points  by  making  the  platform’s  current 
iocation  its  guide  point  and  deleting  the  remainder  of  its  path.  This  is  done  so  that  the 
autopilot,  if  engaged,  will  simply  bring  the  platform  to  a  stop  instead  of  heading  out  di¬ 
rectly  for  the  goal.  The  portion  of  the  path  traversed  so  far  is  preserved  on  the  front  of 
the  list. 

4)  Finally  a  position  update  message  is  sent  over  the  network  on  both  broad¬ 
cast  and  stream  channels.  Currendy  it  is  this  UPDATE  message,  with  its  guidance 
field  set  to  ON,  which  triggers  the  AI  agent  to  calculate  an  optimal  path  based  on  glo¬ 
bal  terrain  cost  data.  However,  there  is  nothing  in  the  vehicle  simulator  to  prevent 
the  AI  agent  from  choosing  the  start  and  goal  points  by  itself,  sending  a  message  to 
turn  guidance  ON,  and  then  sending  guide  points  from  a  calculated  path. 

External  Guidance  ON  — >  OFF  causes  the  following  actions: 

1)  The  platform’s  external  guidance  flag  is  set  to  OFF.  This  causes  any  incom¬ 
ing  guide  point  messages  for  this  platform  to  be  ignored. 

2)  The  platform’s  path  is  deleted. 

3)  Its  original  assigned  path,  if  any,  is  reloaded. 

4)  The  platform’s  guide  point  is  set  to  the  point  on  the  original  path  closest  to 
the  platform’s  current  location.  In  this  way,  a  platform  taken  off  external  guidance  af¬ 
ter  navigating  a  portion  of  a  path  would  not  go  all  the  way  back  to  the  start  point,  but 
can  complete  the  remainder  of  the  path.  Note  that  the  closest  path  point  is  not  neces¬ 
sarily  the  best  path  point  pick  to  minimize  travel  time  or  some  other  performance  mea¬ 
sure.  Locating  the  best  path  point  is  a  non-trivial  problem  in  itself.  In  some  cases 
the  simple  method  used  will  guide  the  platform  back  to  a  previously  passed  path  point 
or  directly  to  the  goal  point.  Generally  however,  when  assigned  a  path  with  many 
fairly  short  segments,  backtracking  and  loss  of  time  will  be  limited  to  one  half  the 
length  of  the  current  path  segment. 
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5)  Finally,  a  position  update  message  is  sent  over  both  broadcast  and  stream 
channels.  The  guidance  field  of  this  message  reflects  its  new  state  and  directs  the  AI 
agent  to  stop  sending  guide  points. 

D.  COMMUNICATIONS 

The  amount  and  sequence  of  data  that  must  be  passed  over  the  network  is  de¬ 
termined  by  the  functions  to  be  performed.  For  communications  between  vehicle  sim¬ 
ulators,  sufficient  data  is  needed  to  display  the  platform  on  a  remote  simulator  as  well 
as  model  its  movement.  Information  flow  with  the  AI  agent  is  determined  by  the  divi¬ 
sion  of  labor  between  the  vehicle  simulator  and  the  commander,  human  or  machine. 
Updates  are  sent  between  vehicle  simulators  or  to  the  AI  agent  only  when  a  state 
variable  such  as  speed,  course,  weapon  firing,  etc.,  changes.  In  general,  in  communi¬ 
cating  with  other  vehicle  simulators  on  the  network,  the  vehicle  simulators  PUSH  in¬ 
formation  over  the  network  using  broadcast  datagrams  to  any  others  who  might  be 
listening.  Only  upon  initialization  does  the  system  poll  for  a  response. 

There  are  usually  several  methods  to  chose  from  when  communicating  between 
applications  over  a  LAN.  In  the  case  of  the  APS  development  environment,  TCP/IP 
supports  byte  streams,  which  require  dedicated  connections,  and  datagrams,  which 
may  be  connectionless,  and  even  addressless  in  the  case  of  broadcast  datagrams,  or 
may  be  sent  between  connected  hosts.  The  vehicle  simulator’s  use  of  a  PUSH  broad¬ 
cast  system  to  communicate  with  other  vehicle  simulators  is  adequate  for  the  amount 
and  types  of  messages  needed  by  that  portion  of  APS.  It  would  have  been  simpler  if 
this  same  approach  could  have  been  used  for  communicating  with  the  AI  agent. 
Broadcast  datagrams  provide  for  reliable1  transmission  of  discrete  messages  over  a 
LAN.  This  means  that  specific  addresses  need  not  be  hard  coded  or  determined  at 


1  Datagrams  are  not  usually  considered  “reliable"  because  there  is  no  receiver  acknowledgement  It  communication  between  hosts 
is  enurely  mtra-network  then  the  underlying  protocol,  in  this  case  Ethernet's  CSMA/CD,  guarantees  delivery  to  each  host  and, 
barring  buffer  overflow  or  process  termination,  the  message  will  reach  each  process  properly  attached  to  the  addressed  port 
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run  time  and  that  each  read  will  return  zero  or  one  complete  discrete  message 
(provided  the  message  fits  within  the  network  maximum  size).  However,  this  proved 
not  to  be  feasible  primarily  due  to  the  limitations  of  the  Symbolics’  implementation  of 
support  for  TCP/IP  network  services.  The  only  arrangement  that  worked  during  this 
research  was  a  pair  of  halfduplex  stream  connections,  with  the  further  limitation  that 
the  vehicle  simulator  must  act  as  the  server  and  the  Symbolics  as  the  client.  For  con¬ 
sistency,  communications  between  AI  processors  also  use  stream  connections. 

The  only  remaining  design  decision  for  the  vehicle  simulator  end  of  the  communi¬ 
cations  link  was  then  whether  to  have  the  simulator  poll  the  incoming  stream  connec¬ 
tion  for  input  using  a  non-blocking  read  or  to  spawn  a  sub-process  to  continuously 
monitor  the  connection  and  communicate  with  the  main  simulator  process  through 
semaphores  and  a  shared  memory  buffer  to  hold  messages. 

A  separate  subprocess  carries  the  additional  complexity  of  implementing  sema¬ 
phores  and  shared  memory  plus  the  computational  overhead  of  a  context  switch.  Al¬ 
so,  during  development,  when  system  aborts  are  common,  special  care  must  be  taken 
not  to  leave  orphan  subprocesses  when  the  main  process  terminates.  The  main  ad¬ 
vantages  are  immediate  response  to  incoming  messages  and  message  preprocess¬ 
ing.  The  subprocess  issues  a  normal  blocking  read  on  the  connection,  which  sleeps 
until  input  is  present.  This  is  more  efficient  than  constantly  polling.  The  second  plus 
is  the  ability  to  respond  immediately  to  some  query  while  the  main  processes  may  be 
tied  up  in  computation  and  graphics  processing. 

The  polling  approach  is  simpler.  In  fact,  in  APS  even  the  initial  acceptance  of  a 
connection  request  is  done  by  polling.  On  a  single  processor  system,  one  CPU  still 
must  run  both  the  main  and  subprocesses  so  no  real  time  is  being  gained  by  running 
them  in  parallel.  There  may  be  some  concern  that  the  input  buffer  may  overflow 
between  polls,  which  in  APS  happen  once  each  drawing  cycle.  However,  under  UNIX, 
the  receive  buffer  can  be  made  practically  as  large  as  desired  (currendy  40K  bytes)  or 
at  least  as  large  as  the  shared  memory  buffer  is  likely  to  be,  so  the  risk  of  overflow 
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between  cycles  is  the  same.  The  system  network  daemon  basically  does  the  same 
job  as  the  subprocess,  and  hopefully,  it  is  more  efficient  at  it  than  user  written  code 
would  be.  Tests  using  dummy  AI  agent  programs  which  send  messages  at  ten  times 
the  normal  rate  have  not  produced  evidence  of  a  lost  message. 

Communications  with  the  Symbolics  AI  agent  are  performed  as  follows: 

1)  Upon  initialization,  the  vehicle  simulator  establishes  a  stream  socket,  sets  it 
to  non-blocking  operations,  increases  its  receive  buffer  size,  and  creates  a  connection 
queue  as  a  stream  server. 

2)  Thereafter,  during  each  graphics  cycle,  the  socket  is  polled  by  issuing  a  non- 
blocking  ACCEPT  command.  If  a  stream  client,  in  this  case  the  Symbolics,  is  waiting 
for  a  connection,  two  stream  sockets  are  cloned,  one  for  receiving  messages  from  the 
Symbolics  and  a  separate  one  for  sending  messages  to  it. 

3)  If  a  working  connection  is  established,  then  a  non-blocking  read  is  issued  on 
the  receive  stream  socket.  Messages  from  the  AI  agent,  comprised  of  character 
strings  with  punctuation  character  delimiters  are  extracted  from  the  stream  and  re¬ 
turned  as  whole  messages  to  the  simulator  which  takes  the  appropriate  action.  The 
specifics  of  how  this  is  implemented  are  contained  in  Chapter  IV.  If  the  stream  con¬ 
nection  is  broken  by  the  AI  agent,  then  a  flag  is  set  and  the  system  returns  to  polling 
for  a  connection  instead  of  polling  for  data  to  read. 

At  the  Symbolics  AI  agent,  the  path  planner  needs  to  monitor  the  progress  of 
the  vehicle,  independent  from  the  vehicle  simulator  updates.  This  means  that  calls  to 
the  communications  system  can  not  be  allowed  to  wait  for  data.  For  this  reason  com¬ 
munications  at  the  Symbolics  AI  agent  is  done  using  the  read-char-no-hang  method 
to  read  the  input  stream.  This  allows  reads  from  the  I/O  stream  to  return  nil. 

Messages  are  identified  and  delineated  by  non  alphanumeric  characters.  Non  al¬ 
phanumeric  message  delimiters  were  chosen  to  reduce  the  chance  of  processing  par¬ 
tial  messages.  This  could  occur  if  the  first  part  of  a  message  were  lost  over  the 
network.  It  is  assumed  that  a  properly  delineated  message  is  complete  and  correct. 
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The  use  of  a  data  stream  requires  that  the  formats  of  the  messages  be  known  in 
advance,  and  that  each  message  be  identified  as  to  type.  This  is  accomplished  by  the 
use  of  non  alphanumeric  delimiters  as  mentioned  above.  A  further  precaution  that  en¬ 
sures  messages  are  not  lost  forever  should  one  message  arrive  without  its  leading 
delimiters  is  the  use  of  different  length  delimiters  on  the  front  and  back  of  messages. 
The  front  delimiter  is  longer  than  the  back  delimiter.  This  is  done  to  prevent  a  mes¬ 
sage  that  has  lost  its  front  delimiter  from  starting  a  cycle  of  reads  that  could  pass 
over  the  correct  first  delimiter.  The  algorithm  that  receives  the  messages  on  the  Sym¬ 
bolics  workstations  checks  for  the  first  delimiters,  and  then  reads  in  a  prespecified 
number  of  characters,  based  on  the  message  type.  The  last  few  characters  make  up 
the  ending  delimiter.  It  should  be  noted  that  the  sending  process  supplies  a  null  char¬ 
acter  between  messages.  If  the  ending  delimiter  were  the  same  length  as,  or  longer 
than  the  beginning  delimiter,  the  ending  delimiter  could  be  interpreted  as  the  begin¬ 
ning.  Since  the  rest  of  the  message  is  not  evaluated  until  the  ending  delimiter  is 
checked,  message  traffic  could  remain  out  of  synchronization  indefinitely  once  broken. 

E.  PERFORMANCE  MEASURES 

In  order  to  make  quantitative  comparisons  among  path  planning  algorithms  or 
human-machine  control  arrangements,  some  numerical  figure  of  merit  must  be  cho¬ 
sen.  For  tactical  vehicles  travelling  cross-country,  some  candidates  are:  transit  time, 
fuel  consumption,  enemy  exposure,  weapons  line-of-sight,  etc.  In  this  study  transit 
time  ‘'as  chosen  because  it  can  be  tied  directly  to  the  terrain  data  base  and  platform 
characteristics. 

For  each  platform  experiment  or  trial,  there  is  a  global  planning  time  and  a 
transit  time.  In  a  sense,  the  planning  time  represents  a  fixed  investment  cost  and 
transit  time  operating  cost.  An  experiment  may  compare  total  time  (planning  and 
transit  time)  or  analyze  them  separately.  As  an  example  of  the  type  of  trade-off 
study  that  might  be  made,  consider  the  current  path  planning  algorithm  used.  Such  a 
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wavefront  or  breadth-first  algorithm  may  not  represent  the  fastest  way  to  produce  an 
optimal  global  path.  However,  its  nature  as  a  neighbor-based  algorithm  means  that 
each  path  step  is  calculated  only  on  LOCAL  cost  data.  Then,  assuming  the  agenda  is 
preserved,  when  a  small  piece  of  the  data  changes,  such  as  the  discovery  of  an 
obstacle,  only  a  small  region  need  be  recalculated.  Its  overall  performance  in  the 
presence  of  constandy  changing  local  data  might  be  superior. 

This  research  makes  no  attempt  to  produce  a  definitive  measure  of  effective¬ 
ness.  Rather  a  mechanism  is  sought  that  will  provide  a  basis  of  comparison  for  oth¬ 
ers  to  use  in  measuring  the  effectiveness  of  path  planning  systems. 

F.  SUMMARY 

This  chapter  provides  an  examination  of  the  source,  thought  process,  and  evolu¬ 
tion  of  the  design  of  APS.  The  development  of  the  vehicle  motion  model  and  control 
response  of  the  vehicle  simulator  are  discussed  along  with  the  knowledge  base  of  the 
rule-based  path  planner  and  path  planning  algorithms.  This  chapter  concentrated  on 
the  why.  The  next  chapter  will  delineate  the  how. 
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IV.  SYSTEM  DESCRIPTION 


This  chapter  describes  how  the  methodology  and  algorithms  were  implemented, 
including  the  function  and  structure  of  some  of  the  main  programs  and  rule  sets.  Data 
structure  definitions  along  with  some  code  listings  are  contained  in  Appendix  A. 

A.  TERRAIN  DATABASE 

APS  uses  terrain  data  that  is  a  subset  of  a  vegetation  and  elevation  database  in 
12.5  meter  increments  for  an  area  of  Ft  Hunter  Liggett,  California,  provided  by 
CDEC.  This  database  is  preprocessed  into  100  meter  resolution  data  by  sampling  ev¬ 
ery  eighth  point  and  then  stored  in  a  separate  file  that  is  read  by  APS.  Each  data 
point  is  16  bits  (2  bytes).  The  3  most  significant  bits  form  a  vegetation  code  which  is 
used  to  color  terrain  polygons  in  a  shade  of  green  for  the  3D  view.  If  the  vegetation 
code  indicates  light  or  no  vegetation,  or  no  vegetation  data  is  available,  then  the  ter¬ 
rain  polygon  is  colored  according  to  its  elevation  using  the  currently  designated  color 
map,  usually  shades  of  brown.  The  remaining  13  bits  contain  the  elevation  in  feet. 
This  elevation  is  used  to  draw  the  3D  terrain,  calculate  normals  for  the  lighting  model, 
and  calculate  slope  used  by  the  path  planning  cost  function. 

APS  is  currently  limited  to  the  35  KM  by  35  KM  area  for  which  preprocessed 
data  is  available.  In  UTM  10  meter  grid  coordinates,  this  area  extends  from 
10SFQ4 1006000  to  10SFQ77009500.  A  basic  terrain  surface  patch  is  formed  by  the 
four  elevations  of  the  vertices  of  a  100  meter  square.  These  points  are  not 
necessarily  planar.  Since  the  IRIS  cannot  quickly  render  filled  non  planer  polygons, 
this  polygon  is  divided  along  a  NW  to  SE  diagonal  into  two  planar  triangles  which  are 
rendered  as  filled  shaded  triangles.  This  basic  terrain  patch  is  shown  in  Figure  4-1. 
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The  lower  left  (SW)  triangle  is  called  the  lower  triangle  and  the  upper  right  (NE) 
triangle  is  the  upper  triangle. 


Figure  4  -  1  Terrain  Patch 


The  elevation  of  each  triangle  vertex  is  stored,  along  with  its  X  and  Z  offsets  in 
a  floating  point  array  (the  upper  left  and  lower  right  points  are  duplicated)  consisting 
of  72  bytes  (3  X  6  X  4bytes)  per  100  meter  square.  In  addition,  a  surface  normal  3D 
vector  is  calculated  and  stored  for  each  triangle.  One  square  kilometer  of  terrain  data 
thus  consumes  9600  bytes  (10  X  10  X  96bytes).  The  entire  35  KM  by  35  KM  area 
consumes  over  1 1  Mbytes  of  memory.  To  maintain  performance,  only  the  vertex  and 
normal  data  for  a  10  KM  by  10  KM  area  selected  by  the  user  are  kept  in  memory. 

B.  VEHICLE  SIMULATION 

1.  Capabilities 

The  capabilities  of  the  Autonomous  Vehicle  Simulator  include: 

•  Acceleration  due  to  changes  in  engine  throttle  (thrust). 

•  Deceleration  due  to  coasting  and  braking. 

•  Change  in  vehicle  pitch  due  to  acceleration  or  braking  proportional  to  the  mag¬ 
nitude  of  the  change  of  velocity. 

•  Vehicle  roll  due  to  centrifugal  force  while  turning. 

•  Linear  steering  controls  with  exponential  steering  response. 

•  Damped  vehicle  oscillations  due  to  changes  in  vehicle  pitch  as  vehicle  travels 
over  varying  terrain. 

•  Change  in  vehicle  velocity  due  to  terrain  slope. 


•  An  autopilot  that  will  navigate  a  platform  along  a  designated  path. 

•  The  ability  to  handle  vehicle  control  inputs  from  either  local  driver  controls,  lo¬ 
cal/remote  autopilot  steering  commands  or  remote  autopilot/commander  path 
commands. 

•  Models  multiple  vehicles,  with  selectable  independent  views  from  each  vehicle 
representing  weapon  sights,  commander’s  station  view,  etc. 

•  Multiple  independent  viewing  axis  and  viewing  positions. 

•  Multiple  independent  weapon  system  axis  maintained  to  provide  for  stabilized 
weapon/sighting  systems. 

•  Utilizes  graphics  hardware  for  fast  coordinate  system  transformations. 

•  The  ability  to  sight,  range,  and  fire  weapon  systems,  including  stabilized 
weapon  systems.  The  following  platforms  and  weapons  are  implemented: 
tank  with  main  gun  SABOT  and  HEAT  rounds,  open  jeep,  closed  top  jeep. 
TOW  jeep,  truck,  Cobra  attack  helicopter  with  TOW  w  eapon,  and  FOGM. 

•  ANSI  C  standard  source  code. 

•  Broadcast  networking  to  allow  multiple  simulations  to  operate  together  on  dif¬ 
ferent  IRIS  workstations. 

A  complete  discussion  of  the  user  interface  for  APS  can  be  found  in  Appendix  C. 

2.  APS  Environment 

The  vehicle  control  and  motion  model  requires  an  interface  with  its  simula¬ 
tor  environment  in  four  areas:  maintenance  of  and  access  to  terrain  data  structures: 
timing;  control  inputs;  and  display  of  results.  From  the  terrain  data  structures,  it 
needs  the  elevation  of  an  arbitrary  point  in  world  coordinates.  This  is  provided  by  the 
function  gndjevel.  It  also  requires  the  surface  normals  for  each  terrain  polygon.  Tim¬ 
ing  is  provided  by  the  routines  in  module  slmtlme  (Appendix  A).  Control  inputs  are 
provided  by  reading  the  mouse  position,  reading  dial  positions,  or  receiving  commands 
from  a  remote  guidance  system.  Displaying  the  results,  which  after  all  is  the  main 
thrust  of  the  simulation,  is  accorr.-j.  ..shed  by  drawterrain  after  the  model  "positions" 
the  vehicle  for  drawing  and  sets  up  the  viewing  parameters  and  the  projection  trans¬ 
formation. 


3.  Graphics  Drawing  Cj  ’le 

Typically,  window-based  graphics  programs  operate  in  a  drawing  cycle 
with  an  I>'P'JT-UPDATE-DISPLAY  loop.  A  representation  for  this  cycle  in  the  vehi¬ 
cle  simulator  is  shown  in  Figure  4-2.  The  platform  modeling  routines  operate  in  the 
update  portion  of  this  cycle.  They  operate  on  the  platform  data  structure  which  is  then 

initialize  terrain,  graphics ,  and  I/O 
while  (  state  variable  ) 

( 

update  simulation  timer 
while  input  in  input  queue 

t 

read  queued  input  device 
handle  input 

} 

handle  network  input  messages 
update  guide  points  and  controls  (autopilot) 
update  vehicle  model 
update  vehicle  position 
draw  objects 

send  network  update  messages 

Figure  4  -  2  Structure  of  Main  Drawing  Loop  in  event_driving 

passed  on  to  the  display  cycle.  The  only  parameters  usually  required  for  model  rou¬ 
tines  are  a  pointer  to  the  platform  and  the  elapsed  time  since  the  last  update  cycle 
was  completed. 

4.  Input 

As  discussed  earlier,  control  inputs  can  have  several  sources,  can  be  set 
to  override  each  other,  and  can  be  turned  on  or  off  depending  on  the  internal  state  of 
the  simulator.  The  source  of  control  inputs  is  largely  irrelevant  to  the  design  of  the 
motion  model  except  for  steering.  Two  ways  of  modeling  steering  correspond  to  two 
types  of  physical  control  systems.  In  one,  the  steering  wheel  or  control  device  is 


directly  connected  to  the  wheels,  tracks  or  control  surfaces  of  the  vehicle  (Figure  4- 
3).  External  course  commands  then  must  be  processed  into  signals  to  a 
servomechanism  which  physically  moves  the  steering  control  just  as  a  human 
operator  would  manipulate  it. 


Figure  4  -  3  Manual  and  Automatic  Steering  Control 


Another  arrangement  is  "fly-bv-wire"  (Figure  4-4)  where  manual  control 
generates  a  signal  which  is  perhaps  one  of  several  input  signals  to  a  steering  control 
system  which  in  turn  activates  physical  control  surfaces  such  as  wheels,  tracks,  or  ai- 


MANUAL 
CONTROL 

COURSE 

COMMANDS 


Figure  4  -  4  "Fly-by- Wire”  Steering  Control 


lerons. 

APS  currently  uses  the  First  system.  Course  commands  are  convened  in¬ 
to  a  tumrate.  This  turnrate  is  then  used  by  model  routines  steering_model  and  turn- 
lng_modeJ  without  caring  if  it  came  from  the  steering  wheel  or  remote  commands. 
Thus  the  modeling  of  turning  is  independent  of  the  source  of  the  turning  commands. 


5.  Model  Update 

The  update  phase  (Figure  4-5)  is  actually  split  into  two  sub-phases.  In 

* 

the  first  phase,  the  new  velocity  and  course  are  calculated.  In  addition,  any  transient 
pitch  or  roll  caused  by  a  change  in  velocity  is  calculated. 


COMMAND  COURSE 
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COMMAND  TURNRATE 
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CURRFNT  TURNRATE 
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COMMAND  VELOCITY 

MODEL 

TRANS  PITCH 

CURRENT  VELOCITY 

TRANS  ROLL 

DT 

Figure  4  -  5  Vehicle  Model  Update  Phase 


Once  the  model  has  updated  the  platform  data  structure,  it  is  passed  on  to 
the  routine  update_veh_pos  which  "moves"  the  platform  to  its  new  location  and  calcu¬ 
lates  orientation  angles  based  on  the  slope  of  the  terrain.  Any  oscillations  or 
"bounce"  in  vehicle  transient  pitch  angle  is  calculated  by  handle__bounce.  This  is 
based  on  the  change  in  vehicle  base  pitch  angle  exceeding  some  threshold  or  mini¬ 
mum  change.  At  this  point,  an  interplay  exists  between  attempting  to  smooth  abrupt 
pitch  changes  between  adjoining  terrain  patches  and  simulating  bounce.  Because  the 
terrain  is  represented  by  patches,  the  flat  tops  of  hills  or  ridges  that  are  less  wide 
than  the  terrain  cell  size  are  "missed"  by  the  data  base.  Consequently  cresting  a  hill 
and  going  down  the  other  side  is  portrayed  as  an  instantaneous  change  from  positive 
to  negative  slope  as  the  line  separating  the  two  adjoining  patches  is  crossed.  To 
smooth  out  this  sharp  transition  the  length  of  the  baseline  to  the  front  of  the  vehicle 
used  to  calculate  base  pitch  was  extended  forward  about  20  meters.  This  results  in 
the  pitch  change  being  spread  over  smaller  increments  as  the  reference  point  moves 
down  the  far  slope  as  the  vehicle  is  coming  up  the  near  side.  Unfortunately  this 
smoothing  can  also  "smooth"  oscillations  out  of  existence.  Only  experimentation 
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with  the  constants  pltchbase_distance  and  bounce_threshold  can  produce  a  realistic 
compromise. 

6.  Platform  Position  and  Viewing  Parameter  Update 

APS  updates  the  vehicle  posidon  and  orientation  variables  whether  or  not 
the  vehicle  is  currently  selected  as  the  viewing  platform,  the  driven  vehicle.  Ln  MPS 
the  viewer’s  position  was  not  fixed  with  respect  to  the  driven  vehicle  coordinate  sys¬ 
tem.  It  was  a  constant  Y  offset  from  the  vehicle’s  graphical  center  in  world ,  not  body 
coordinates.  On  fairly  level  terrain  this  works  well,  but  as  the  vehicle  pitches  and 
rolls  when  travelling  over  rough  or  sloping  terrain  the  viewpoint  or  eye  position  aD- 
pears  to  bounce  around  inside  the  vehicle.  This  movement  is  disorienting  and  in  some 
cases  may  even  result  in  viewing  the  terrain  from  underneath  the  terrain  polygons. 
One  solution  to  this  problem  is  simply  to  not  draw'  the  driven  vehicle.  However,  the 
viewer  then  looses  the  frame  of  refere...e  the  vehicle  outline  provides,  especially 
when  the  view  angle  is  not  directly  to  the  front.  A  more  satisfactory  solution  is  to  de¬ 
fine  the  viewpoint  as  an  offset  from  the  vehicle  origin  in  vehicle  (body)  coordinates 
and  transform  the  viewpoint  into  the  graphics  (world)  coordinates  required  to  estab¬ 
lish  the  viewing  perspective.  Such  a  transformation  also  allows  the  viewpoint  to  be 
placed  at  an  arbitrary  point  in  the  vehicle  which  could  represent,  the  gunner's  sight, 
commander’s  cupola,  etc.  Setting  the  viewing  perspective  is  then  done  as  shown  in 
Figure  4-6  where  eye_x,  y,  z  is  the  sum  of  vehicle  position  coordinates  and  the  view- 

perspective!  fov,  1.0,  0.1,  MAXLOOKDIST  ); 
lookat(  eye_x,  eye_y,  eye_z, 

local _px,  local _py,  locai_pz,  (Angle)(vlewroll*RTOD_X_iO) ); 

Figure  4  -  6  Setting  Projection  Parameters 


ing  point  offset  in  transformed  world  coordinates. 

The  IRIS  graphics  software  also  requires  a  viewing  "target''  (local _px,  y, 
z).  for  the  lookat  perspective  routine.  The  homogeneous  transform  again  provides  a 
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means  for  calculating  this  visual  target  since  it  is  simply  a  constant  displacement 
along  the  body  X-axis  of  the  viewer.  This  corrects  simplifications  in  MPS  that  ne¬ 
glect  cant  or  body  roll  in  determining  point  of  view.  This  precision  becomes  important 
when  a  weapon  system  is  modeled  because  the  point  of  view  is  also  the  point  of  aim. 
A  one  degree  error  in  azimuth  caused  by  cant  corresponds  to  a  18  meter  error  at  a 
range  of  1000  meters.  Therefore,  the  MPS  routine  update_look_pos  was  modified  to 
use  this  procedure. 

7.  Network  Communications 

As  described  in  Chapter  III,  communications  among  vehicle  simulators  is 
handled  differently  than  communications  with  the  AI  agent.  Messages  among  vehicle 
simulators,  whether  each  is  functioning  as  a  peer  or  a  remote  human  commander,  are 
passed  over  the  network  using  broadcast  datagrams,  while  the  vehicle  simulator  and 
the  AI  agent  communicate  using  a  stream. 

Communication  routines  are  divided  into  two  levels:  the  APS  message  lev¬ 
el  and  the  network  service  level.  These  levels  and  the  modules  that  contain  level 
routines  are: 

APS  message  level  check_for_packets  (receive) 

network  (send) 

message- stream  management  network_IO 

network  system  sendees  netstream_senices 

broadcast_sen  ices 

a.  Vehicle  Simulator  Communications 

(1)  Initialization.  Two  network  sockets,  a  transmit  socket  and  a 
receive  socket,  are  initialized  for  each  vehicle  simulator.  The  receive  socket  is  bound 
to  an  address  containing  the  APS  broadcast  port  number.  This  port  number  is 
arbitrary,  but  must  be  unique  to  avoid  interference  w'ith  other  network  sendees  such 
as  “mair  and  “rwho”  and  must  be  the  same  for  all  vehicle  simulators.  In  APS,  the 
broadcast  port  number  is  a  program  constant  (DEFAl'LT_BRDCAST_PORT  in 
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network. h).  An  alternative  method  of  assigning  a  port  is  by  defining  a  "service"  in  the 
network  system  file  "/etc/services".  The  system  service  getservbyname  can  then  be 
used  to  determine  the  port  number  at  run  time.  This  method  has  the  advantage  of 
allowing  changes  in  the  port  number  without  recompiling  the  program  should  the  port 
assignment  interfere  with  some  other  network  application.  However,  each  system 
running  a  vehicle  simulator  must  have  the  same  service  definition  for  APS.  Finally, 
each  socket  is  set  to  BROADCAST  mode,  non-blocking  I/O,  and  has  its  buffer  size 
increased  to  RECVJBUFSIZE  (currently  40K  bytes).  Since  the  most  common 
broadcast  message  is  an  UPDATE  packet  with  a  size  of  180  bytes,  each  vehicle 
simulator  can  normally  receive  =  220  packets  before  the  buffer  overflows.  In 
communication  tests,  no  such  loss  of  message  traffic  has  yet  been  observed. 

After  the  sockets  are  established,  each  vehicle  simulator  sends  a 
polling  message  to  synchronize  itself  with  any  other  already  running  simulators.  A 
response  to  this  initialization  message  sets  the  initial  10  KN1  terrain  box  to  that  area 
already  being  viewed  by  a  running  simulator. 

(2)  Sending  Messages.  Messages  are  sent  as  character  strings 
divided  into  a  header  string  that  identifies  the  type  of  message  and  a  varying  length 
data  string.  The  first  character  in  the  header  string  is  a  message  token,  a  character 
that  uniquely  determines  the  message  type.  The  resf  of  a  message  is  the  formatted 
output  of  a  sprint  command  containing  from  one  to  thirteen  fields.  All  messages  are 
built  and  sent  by  routines  in  module  network().  This  routine  is  called  with  one 
argument  indicating  the  type  of  message  that  is  requested.  Message  types  are 
shown  in  TABLE  1.  The  function  network()  also  contains  several  local  static  variables 
which  contain  data  used  in  building  a  message.  For  example,  to  send  an  UPDATE 
message  the  routine  set_cntlmsg_platform(platform_polnter)  ;s  called  to  set  the 
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vehicle  then  network(SEND  UPDATE_PACKET)  is  invoked  to  build  and  dispatch  the 
message. 

TABLE  4-1  VEHICLE  SIMULATOR  MESSAGE  TYPES 


TYPE 

FIELDS 

DESCRIPTION 

INTT_MESSAGE 

Polls  for  other  vehicle  simulators. 

ANS_MESSAGE 

x_grid,  y_grid 

Answers  INIT_MESSAGE  and 
sets  origin  of  10KM  box. 

UPDATE_PACKET 

vehicle  id,  type, 

UTM  x,y,  course, 
speed,  weapon  azimuth, 
weapon  elevation, 
transient  pitch,  transient 
roll,  control  mode, 
external  guidance. 

Updates  platform  data  on  remote 
vehicle  simulators. 

END.PACKET 

base  id  number 

Tells  remote  vehicle  simulators  to 
delete  all  platforms  belonging  to 
this  host. 

FIRE.MESSAGE 

firer  x,y,z,  target  x.y.z, 
weapon  azimuth, 
weapon  elevation 

Sends  a  weapon  system  firing 
event.  The  flight  of  the  projectile 
is  then  modeled  on  each 
simulator. 

LOCK_ON_MESSAGE  vehicle  id 
LOCK_OFF_MESSAGE 

Sends  id  of  platform  that  is/is  not 
being  tracked  by  FOGM. 

DESTROY.MESSAGE  vehicle  id 
CRASH_MESSAGE 

Sends  message  notifying  remote 
simulators  that  platform  has  been 
destroyed. 

(3)  Receiving  Messages.  Since  datagrams  contain  discrete  APS 
messages,  the  type  of  an  incoming  message  is  determined  by  matching  .he  first 
character  of  the  header  string  with  a  character  token.  The  data  string  is  then 
disassembled  by  a  formatted  string  read  fsscanf  in  C)  and  the  appropriate  action  faken. 
This  message  handling  occurs  in  module  check_for_packets().  Once  during  each 
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drawing  loop  this  routine  is  called.  It  loops  handling  messages  until  no  input  is 
available. 

b.  Vehicle  Simulator  •  Al  Agent  Communications 

(1)  Initialization.  The  communications  stream  is  set  up  by  initializ¬ 
ing  a  stream  socket,  setting  it  to  non-blocking  I/O,  increasing  its  buffer  size  to 
RECV_BUFSIZE  bytes,  and  establishing  a  connection  queue  by  calling  the  listen 
system  service.  The  socket  is  then  polled  once  each  drawing  cycle  using  a  non-block¬ 
ing  accept  system  service.  Two  sockets  are  then  cloned  to  handle  the  receive  and 
transmit  streams  and  a  global  flag,  control_connected,  is  set  indicating  a  connection 
with  the  AI  agent  has  been  established. 

(2)  Sending  Messages.  Messages  are  sent  as  a  continuous  string 
of  characters  with  no  imbedded  "white  space”  characters  such  as  spaces,  tabs,  or 
linefeed.  All  numeric  fields  must  be  zero  filled.  Each  message  is  preceded  by  a  fixed 
number  of  a  unique  delimiter  token  characters,  usually  a  punctuation  character,  {,?,@, 
etc..  The  variable  length  data  string  follows.  A  message  is  terminated  by  a  number 
of  delimiter  characters,  one  less  than  at  the  front  of  the  message.  Since  stream  I/O 
implies  an  unbroken  flow  of  data,  these  front  and  read  delimiter  characters  serve  to 
identify  the  type  of  message  and  provide  begin  and  end  message  markers  at  the  pro¬ 
gram  level.  This  additional  framing  allows  resynchronization  should  a  portion  of  a 
message  be  lost  or  garbled.  It  also  allow  recognition  of  different  type  messages  by  a 
simple  finite  state  machine.  Messages  to  the  AI  agent  are  built  and  sent  by  calling 
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routine  control_message(message_type)  contained  in  the  module  network.  The  types 


of  messages  sent  to  the  AI  agent  are  contained  in  Table  2: 

TABLE  4-2  VEHICLE  SIMLLATOR  to  AI  AGENT  MESSAGE  TYPES 


TYPE 

FIELDS 

DESCRIPTION 

INITIALIZE 

UTM  x,y  of  10KM  box 
origin,  vehicle  id, 
path  stan  x,y  goal  x,y, 
simulation  time 

Tells  AI  agent  which  plaworm  to 
plan  path  for  and  what  part  of 
terrain  database  to  load. 

UPDATE 

vehicle  id,  vehicle 
location  UTM  x,y, 
simulation  time, 
guidance  flag 

Updates  platform  data.  Initial 
guidance  ON  message  triggers 
path  calculation. 

OBSTACLE 

obstacle  vertices 

Sends  coordinates  of  vertices  of 
detected  obstacle. 

CONTROL 

vehicle  id, 
simulation  time, 
control  code 

Sends  status  and  control  flags. 

(3)  Receiving  Messages.  Routine  check_for_packets()  also 
handles  incoming  stream  messages  by  calling  recv_control_message().  If  no  AI  agent 
is  connected,  it  polls  for  a  connection.  If  it  can  form  a  valid  APS  message  from 


characters  in  an  internal  buffer,  then  it  returns  TRUE  otherwise  it  returns  FALSE. 
Messages  are  recognized  using  a  finite  state  machine.  Incoming  characters  are 
returned  to  recv_control_message()  by  get_msgchar(),  which  returns  the  next 
character  in  the  block  buffer  and  keeps  the  buffer  filled  as  necessary  by  reading  the 
stream.  If  the  stream  read  returns  0,  then  the  client  has  broken  the  connection  so  the 
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current  message,  if  any,  is  discarded  and  the  flag  is  set  to  begin  polling  for  a 
reconnection.  Message  types  received  from  the  AI  agent  are  contained  in  Table  4-3. 

TABLE  4-3  AI  AGENT  to  VEHICLE  SIMULATOR  MESSAGE  TYPES 


TYPE 

FIELDS 

DESCRIPTION 

GUIDEPT 

vehicle  id, 

If  external  guidance  is  set  for  plat- 

path  point  UTM  x,y 

form  matching  vehicle  id,  then  the 
platform’s  guide  point  is  replaced 
by  the  incoming  point.  If  recv_path 
is  set  for  platform  then  incoming 
point  is  added  to  path  being  built. 

CONTROL 

vehicle  id. 

Turns  guidance  ON/OFF, 

simulation  time, 

recv_path  ON/OFF.  or 

control  code 

autopilot  ON/OFF. 

8.  Simulation  Time 

It  is  often  desirable  to  change  the  speed  at  which  the  simulation  runs  by 
modifying  the  ratio  between  real  (clock)  time  and  simulation  time.  This  is  done  by  fil¬ 
tering  calls  to  the  system  clock  through  the  simtime  module.  This  allows,  for  example, 
simulation  time  to  be  suspended  while  menus  are  displayed.  The  routines  available  are 
shown  in  Figure  4-7. 

9.  Simulating  Weapon  Systems 

Platforms  in  APS  can  be  equipped  with  weapon  systems  by  defining  the 
weapon’s  characteristics,  ammunition  types,  and  sight  reticle.  A  platform  with  a  weap¬ 
on  system  can  engage  and  destroy  any  other  platform,  local  or  remote.  Figure  4-8 
shows  the  view  through  a  TOW  weapon  sight  looking  at  an  attack  helicopter.  Weapon 
data  structure  definitions  are  contained  in  "weapons. h”  which  is  reproduced  in  Appen¬ 
dix  A.  Current  weapons  include  tank  main  gun  with  SABOT  and  HEAT  rounds  and  the 
TOW  antitank  weapon  system. 
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start_simtime()  -  Starts  simulation  time  at  0. 

stop_slmtlme()  -  Halts  simulation  time  from  advancing, 
i.e.  freezes  time. 

restart_simtime()  -  Restarts  simtime  when  halted. 

change_simspeed(  float  ratio  )  -  Changes  the  ratio  of 
simulation  time  /  real  time.  That  Is,  a  ratio  value 
of  0.3  will  cause  simulation  to  run  3  times  slower 
than  real  time,  or  3  seconds  of  real  time  will  elapse 
for  every  1  second  of  simulation  time. 

float  read_slmtimer()  -  Returns  the  current  time  since  start_simtime 
was  called  in  simulation  seconds. 

void  set_time_mark(  void  )  -  sets  a  time  mark  by  storing  current  value 
of  slmtimer  In  local  static  "package"  variable. 

float  elapsed_tlme_wreset(  void  )  -  returns  elapsed  time  in  seconds 
since  time  mark  and  resets  time  mark. 


Figure  4  -  7  Simulation  Timer  Module  Routines 
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Figure  4  -  8  View  Through  TOW  Weapon  Sight 
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Weapon  system  data  structures  are  as  general  purpose  as  possible,  to  fa¬ 
cilitate  addition  of  other  types  of  weapon  systems  and  munitions.  Each  platform  con¬ 
tains  an  array  of  pointers  to  onboard  weapon  systems,  one  of  which  is  selected  as  the 
current  weapon.  Each  weapon  system  is  represented  by  an  instance  variable  which 
contains  data  specific  to  that  platform  and  pointers  to  class  variables  which  contain 
generic  data  for  that  type  of  weapon  or  munition.  The  tank,  for  example,  has  a  pointer 
to  its  weapon  class  variable  and  a  pointer  to  the  munition  class  variable  for  the  partic¬ 
ular  type  of  round  currently  selected.  Which  sight  reticle  is  drawn  is  determined  by 
looking  into  the  weapon  class  variable  of  the  currently  selected  weapon  for  the  cur¬ 
rently  selected  platform.  Presently  tank  mail,  gun,  binoculars,  and  TOW  sight  reticles 
are  available1. 

Target  ranging  is  also  simulated  for  those  weapons  that  normally  have 
such  a  capability.  The  tank,  for  example,  simulates  a  LASER  range-finder  by  doing  a 
gselect  (similar  to  a  graphic  pick)  on  a  three  degTee  field-of-view  along  the  firer’s 
line-of-sight  (LOS).  The  select  list  is  examined  for  platform  identifiers,  except  that 
of  the  firer,  and  returns  the  range  to  the  closest  one.  This  range  is  displayed  in  the 
weapon  sight  reticle.  Platforms  which  no  weapon  system,  such  as  jeeps,  of  course 
have  no  range-finding  capability.  They  have,  however,  been  provided  with  variable 
power  binoculars  selectable  from  the  main  driving  menu. 

Although  range-finding  with  a  LASER  happens  quickly  enough  so  that  it 
can  be  completed  in  a  single  iteration  of  the  drawing  loop,  actions  such  as  the  flight  of 
a  round  extend  over  multiple  drawing  cycles.  In  order  to  support  such  transient 
events  without  congesting  every  possible  drawing  loop  in  APS,  an  event  handler 
which  is  called  once  each  drawing  loop  was  implemented.  Events,  such  as  a  round  in 
flight,  are  implemented  as  a  linked  list  of  event  data  structures  (described  in 
"weapons. h")  with  a  common  pan  containing  a  time  stamp,  delete  flag,  and  pointer  to 

1  Dau  is  unclassified  hypothetical  dau  representing  the  generic  characteristics  of  the  represented  item  and  is  not  intended  to 
exactly  match  any  actual  system. 
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a  function  which  can  process  this  type  of  event.  Each  event  also  contains  a  variant 
part  containing  type-specific  event  data  fields.  Once  each  drawing  loop  the  event 
handler  is  called.  It  traverses  the  event  linked  list.  If  an  event  is  not  marked  for  dele¬ 
tion,  a  call  is  made  to  its  processing  function  via  the  pointer,  with  the  address  of  the 
event  record  as  the  parameter.  This  allows  the  event  processing  function  access  to 
the  type-specific  data.  Types  of  events  currently  implemented  are: 

1)  round_ln_fllght  -  flies  ballistic  trajectory. 

2)  reset_safety  -  dmeout  to  reset  weapon  safety  after  reload  time. 

3)  message  -  displays  message  on  screen  for  set  period  of  time. 

4)  splash  -  draw  splash  of  round  miss  for  specified  amount  of  time 

5)  flash  -  draw  expanding  flash  at  impact  of  round  with  platform. 

6)  bounce  -  varies  vehicle  pitch  based  on  elapsed  time  since  going  over 
bump  in  the  terrain. 

Firing  a  weapon  in  APS  results  in  the  simulation  of  the  projectile's  flight 
until  impact  with  the  ground,  another  platform,  or  maximum  range  is  exceeded.  The 
system  assumes  that  the  weapon  system  has  some  type  of  ballistic  computer  that 
will  provide  elevation  to  the  weapon  based  on  the  range  to  the  target,  type  of  ammuni¬ 
tion,  etc..  This  allows  the  position  of  the  round  along  its  ballistic  path  to  be  computed 
from  a  table  of  offsets  in  the  Y  (UP)  direction,  called  its  ballistic  table,  by  scaling  the 
offset  using  the  current  range  from  the  point  the  round  was  fired.  This  produces  an  or¬ 
dinate  for  the  current  range.  A  cylindrical  viewing  volume  is  then  constructed  along 
the  LOS  at  the  time  the  weapon  was  fired  offset  by  the  ordinate.  LOS  guided  muni¬ 
tions  such  as  the  TOW  are  processed  the  same  way,  except  that  their  ordinate  is  al¬ 
ways  zero  and  the  flight  volume  is  based  on  the  firing  platform’s  current  LOS  not  the 
LOS  at  the  time  of  firing.  The  near  and  far  clipping  planes  are  set  to  the  starting  and 
ending  position  of  the  round  during  the  increment  of  time  since  the  last  update.  This 
cylindrical  volume  is  "swept"  using  gselect  and  the  closest  target  to  the  firing  vehicle 
is  destroyed,  if  it  is  hit.  If  no  target  is  in  the  volume,  the  round  is  checked  for  impact 
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with  the  ground  and  a  splash  drawing  event  is  added  to  the  event  list.  Finally,  if  the 
round  flies  beyond  the  edges  of  the  terrain  box,  or  exceeds  its  maximum  range,  it  is 
terminated. 

10.  Module  Descriptions 

This  section  presents  a  brief  description  of  the  main  modeling  and  simula¬ 
tion  modules. 

a.  Program  Control  Flow 

Program  control  flow  is  determined  by  state  variables  modified  by  the 
user  through  input  from  the  dials,  mouse,  or  menu  system.  Program  structure  is  elab¬ 
orated  in  Appendix  A  and  the  user  interface  including  the  menu  system  in  Appendix  C. 

b.  Supporting  Routines 

Supporting  routines  that  perform  a  single  function  are  too  numerous 
to  fully  describe  here.  A  listing  of  all  modules  is  contained  in  Appendix  A.  Due  to  the 
incremental  development  of  MPS.  some  modules  overlap  in  function. 

c.  Data  Structures 

The  data  used  to  model  vehicle  motion  is  kept  in  the  platform  data 
structure  defined  in  the  "aps.h"  (Appendix  A).  The  platform  data  structure  contains 
several  state  variables  and  toggles  which  are  implemented  as  C  enumerated  types  or 
a  locally  defined  Boolean  type.  These  state  variables  could  be  combined  into  a  single 
variable  using  bit  fields  which  would  be  more  space  efficient.  This  was  not  done  due 
to  the  additional  complexity  of  accessing  bit  fields  and  because  bit  fields  are  perhaps 
the  least  portable  feature  in  ANSI  C. 

d.  Turning/Steering  Module 

Steering  is  modeled  using  three  routines: 

•  float  convert_course_to_turnrate(  Vehicle  'platform  )  -  Converts  command 
course  to  tumrate  which  can  be  fed  to  the  turning  model.  If  the  platform 
viewing  mode  is  driver,  the  input  is  coming  from  the  dials  or  the  autopilot. 
This  input  is  in  the  form  of  a  commanded  course  or  azimuth  and  the  tumrate 
to  direct  the  vehicle  onto  this  course  must  be  computed.  This  computed 
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tumrate  is  stored  in  the  cmd_turnrate  field  of  the  platform  record.  This 
routine  is  implemented  using  the  following  rules: 

i,  If  the  difference  between  the  command  course  and  current  course  is 
less  than  a  small  delta,  CSE_WANDER,  then  make  them  the  same. 

2)  If  the  difference  is  less  than  AUTO_TURNRATE,  then  use  differeno- 
as  tumrate.  Note  that  this  may  cause  oversteer  if  the  update  time  in¬ 
terval  is  greater  than  one  second. 

3)  Otherwise  use  AUTO_TURNRATE. 

•  update_platform_steerIng_model(  Vehicle  ‘platform,  float  elapsedsec, 

Boolean  *network_packet_needed  )  -  This 
routine  first  calls  turnlngjnodel  to  calculate  the  current  tumrate.  It  then  ap¬ 
plies  the  current  tumrate  and  time  interval  to  calculate  a  new  course.  Final¬ 
ly,  the  view'ing  angles  in  the  platform  record  are  adjusted  so  that  the  view 
azimuth  changes  with  the  course. 

•  float  turnlng_model(  float  elapsedsec, 

float  currjumrate, 

float  cmd_turnrate )  -  Returns  exponential  steering  re¬ 
sponse  if  command  tumrate  is  greater  than  current  tumrate.  If  straightening 
out  then  centrifugal  force  is  assisting  so  tumrate  change  is  immediate. 


e.  Velocity  Module 

Consists  of  the  routine  float  velocity_model(  float  dt,  float  slope, 
float  currvel,  float  cmdvel,  float  ‘pitch,  Boolean  *network_packet_needed  ).  This  rou¬ 
tine  returns  the  new  platform  speed  using  methods  described  in  Chapter  III.  It  also 
calculates  and  updates  the  transient  vehicle  pitch  due  to  acceleration  or  braking.  This 
transient  pitch  simulates  the  torque  on  the  vehicle  body  during  sudden  velocity 
change  as  the  vehicle  body  is  constrained  by  the  suspension  system. 

/.  Bounce  Module 

Vehicle  bounce  due  to  changing  terrain  slope  is  started  by  routine 
update_veh_pos  which  sets  the  initial  transient  pitch  angle  amplitude  if  there  is  a 
change  in  vehicle  pitch  greater  than  BOUNCE_THRESHOLD  (currently  two  degrees). 
Routine  handle_bounce  calculates  a  new  transient  pitch  angle  and  updates  the  bounce 
amplitude  field  in  the  vehicle  record.  If  the  bounce  amplitude  has  fallen  below 
PITCH_STEADY  then  it  is  set  equal  to  zero. 
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g.  Math  Module 


Contains  various  general  purpose  math  routines. 

•  float  convert_normal_to_slope(float  normal[3])  -  Returns  the  slope  angle  of 
a  terrain  polygon  in  radians  based  on  surface  normal. 

•  transform_body_to_world(  float  azimuth,  elevation,  roll, 

float  dx,  dy,  dz, 

float  *eye_x,  *eye_y,  *eye_z  )  -  Transform  body 
coordinates  to  world  coordinates. 

•  float  calc_azlmuth{  float  xl,  float  yl,  float  zl,  float  x2,  float  y2,  float  z2  )  - 

Returns  azimuth  in  radians  from  the  positive  X  axis  for  a  course  from  point  1 
to  point2. 

h.  Path  Operations  Menu  Module 

This  module  (contained  in  do_pathops.c)  contains  the  high  level  func¬ 
tions  to  create  and  delete  a  path,  assign  a  platform  to  a  path,  and  toggle  the  display  of 
paths  on  and  off.  When  called  by  selecting  the  "PATH  OPERATIONS"  option  from 
the  main  driving  menu,  in  module  do_drivlng_menu.  a  popup  menu  is  constructed  and 
displayed.  If  a  valid  menu  choice  is  made  then  the  function  selected  is  performed  by 
calling  one  of  the  routines: 

•  build _path  -  Displays  instructions,  initializes  a  path  structure,  adds  a  point 
to  the  path  and  redraws  the  new.  path  each  time  the  left  mouse  button  is 
pressed,  prompts  for  a  path  name  when  right  mouse  button  is  pressed,  adds 
path  to  path  list,  and  updates  path  data  file  to  add  new  path. 

•  select_and_remove_path  -  Displays  instructions,  when  right  mouse  is 
pressed  uses  pick  to  determine  which  path  was  selected,  deletes  path  from 
path  list,  saves  remaining  paths  in  path  data  file. 

•  asslgn_veh_to _path  -  Displays  instructions,  when  right  mouse  is  pressed 
uses  pick  to  determine  which  vehicle  icon  was  selected,  makes  cursor  into 
vehicle  icon,  when  icon  cursor  is  moved  over  any  point  on  a  path  and  right 
mouse  is  pressed  uses  pick  to  determine  which  path  is  selected,  makes  copy 
of  path  for  platform  and  sets  platform’s  guide  point  to  first  point  on  the  path. 
If  platform  is  not  local  sends  path  over  network  to  home  simulator. 

This  module  also  contains  functions  to  pick  and  display  paths: 

•  draw _path  -  Draws  a  single  path  as  a  black  line  with  a  blue  box  around  the 
first  point  and  a  red  circle  around  the  goal.  Paths  are  drawn  in  overlay  bit 


planes  so  that  it  would  not  be  necessary  to  redraw  the  entire  2D  map  each 
time  a  point  is  added  to  a  path. 

•  dlsplay_paths  -  Displays  all  paths  in  normal  drawing  or  pick  mode  depend¬ 
ing  upon  its  argument  and  returns  the  path  identifier  ot  the  picked  path. 

•  plck_path  -  Calls  display_paths  in  pick  mode  and  returns  pointer  to  the  path 
selected  or  NULL  if  no  valid  path  is  selected. 

i.  Path  Module 

This  module  (contained  in  "path.c”)  is  a  package  which  contains  the 
low-level  functions  that  operate  on  paths.  The  path  data  structure  was  shown  in  Fig¬ 
ure  3-7.  Paths  are  only  manipulated  using  the  functions  in  this  module.  Function  pro¬ 
totypes  are  declared  in  "pathfunc.h”.  Since  most  of  these  functions  operate  on  a 
specific  path,  most  have  a  pointer  to  a  PATH  structure  as  one  of  the  input  arguments. 
Path  points  are  kept  as  UTM  coordinates  and  are  convened  to  graphic  system  world 
coordinates  as  necessary.  The  following  functions  are  supponed: 

•  addpt  -  Adds  a  path  point  to  the  end  of  an  existing  path. 

•  addpath  -  Adds  a  parh  fo  the  end  of  the  path  linked  list. 

•  at_goal  -  Returns  TRUE  if  path  point  has  the  same  coordinates  as  the  last 
point  on  a  path. 

•  copypath  -  Copies  path  points  from  one  path  to  another. 

•  delete _path  -  Deletes  path  structure  and  frees  up  space. 

•  delete_list_path  -  Deletes  path  from  path  list. 

•  delete_veh_path  -  Deletes  platform  copy  of  path. 

•  init _path  -  Returns  pointer  to  a  new  path  structure. 

•  load_paths  -  Loads  paths  from  data  file. 

•  nextpt_on _path  -  Returns  pointer  to  the  next  point  on  a  path. 

•  reset_platform_path  -  Clears  platform  path  and  reloads  path  originally  as¬ 
signed  if  any.  Calls  start_down _path  to  set  initial  guide  point  to  path  point 
nearest  platform’s  current  location. 

•  save_paths  -  Writes  out  all  currently  defined  paths  to  binary  file  in  the  cur¬ 
rent  default  directory.  The  file  structure  description  is  contained  in 
"pathdata.h". 

•  set_g"ldept  -  Replaces  the  platform’s  current  guide  point  with  input  argu¬ 
ments  and  discards  remaining  path  points. 
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•  start_down_path  -  Returns  pointer  to  path  point  closest  to  the  input  argu¬ 
ment  point  (usually  platform’s  current  location). 

•  update_guldept  -  If  platform  is  within  VICINITY  meters  of  current  guide 
point  and  that  guide  point  has  a  successor,  set  the  platform’s  guldept  field  to 
point  to  next  point  on  the  path. 

j.  Autopilot  Module 

The  autopilot  works  by  setting  the  platform’s  commanded  course  and 
speed  to  follow  its  assigned  path.  For  each  local  platform  that  has  its  control  field  set 
to  AUTOPILOT  and  has  a  non-NULL  guldept  (i.e.,  it  has  a  point  to  head  towards) 
the  autopilot  performs  the  following  functions: 

1.)  Update  the  guide  point  if  within  a  prescribed  distance. 

2)  Handles  obstacles  (currently  not  implemented). 

3)  Update  the  platform’s  cmdcse  to  the  azimuth  from  the  platform's  current  lo¬ 
cation  to  its  current  guide  point. 

4)  Sets  commanded  speed  depending  upon  the  current  distance  to  the  guide 
point.  If  the  platform  is  so  close  that  it  might  overshoot  the  guide  point  then  braking 
is  applied  by  setting  cmdvel  =  -1.0.  Tne  platform's  course  is  also  frozen  to  a  void 
turning  if  the  autopilot  is  engaged  while  the  platform  is  near  a  guide  point.  Note  that 
the  current  implementation  does  not  control  the  platform  with  sufficient  precision  to 
navigate  an  obstacle  field. 

B.  RULE-BASED  PATH  PLANNER 

The  path  planner  is  implemented  as  three  distinct  levels.  The  top  level  is  re¬ 
ferred  to  as  the  path  planner  control  program.  It  is  through  this  program  that  overall 
control  of  the  path  planner  is  accomplished.  The  intermediate  level  consists  of  the 
search  control  program,  which  is  implemented  on  a  separate  Symbolics  workstation. 
The  search  control  program  controls  access  to  the  implemented  search  algorithm.  Fi¬ 
nally,  at  the  lowest  level  is  the  implemented  search  algorithm.  It  is  located  on  the 
same  Symbolics  workstation  as  its  control  program. 


1.  Path  Planner  Control  Program 

The  path  planner  control  program  is  located  on  the  Symbolics  workstation, 
SYM4.  It  is  implemented  using  ART,  a  rule-based,  expert  system  shell.  The  rules  in 
this  program  control  the  action  of  all  subordinate  processes.  There  are  24  rules, 
grouped  into  the  following  seven  categories. 

•  Set  up 

•  Communications 

•  Clock  actions 

•  Vehicle  monitoring 

•  Vehicle  and  Path  control 

•  Search  control 

•  Fact  clean  up 

This  grouping  of  rules  is  used  for  conveyance  of  explanation,  and  does  not 
necessarily  have  any  bearing  on  the  Firing  order  of  the  rules.  Appendix  B  contains  a 
listing  of  the  cooe. 

a.  Set  Up  Rules 

The  location  of  the  vehicle  simulation  program  and  the  search  are 
variable  as  stated  in  Chapter  III.  This  requires  that  the  user  input  the  location  of 
these  processes  at  the  start  up  ot  the  path  planner  control  program.  Two  menu  rules, 
menul  and  menu2.  are  used  for  this.  These  in  turn  enable  two  communications  start 
up  rules,  start-iris-comm-links  and  start-sym-comm-links.  These  communications 
rules  open  a  TCP/IP  I/O  stream  to  the  vehicle  simulator  process  on  •  •  appropriate 
IRIS  workstation,  and  a  CHAOSNET  I/O  stream  to  the  search  control  program  on  the 
appropriate  Symbolics  workstation.  Program  start  up  is  the  only  time  any  of  these  set 
up  rules  are  Fired. 

b.  Communications  Rules 

The  heart  of  the  path  planner  control  program’s  abilitv  to  monitor  the 
actions  of  other  processes  on  other  machines  is  its  ability  to  receive  information.  This 
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information  is  received  via  seven  communications  rules.  Two  of  these  rules,  check* 
comm-links-iris  and  check-comm-links-sym  are  used  to  continuously  check  the  I/O 
streams  for  incoming  messages.  These  are  the  only  communications  rules  in  the  path 
planner  control  program  that  are  cyclic  in  nature.  These  rules  are  at  the  lowest  active 
precedence  level,  and  therefore  do  not  cause  any  problem  with  indefinite  postpone¬ 
ment  of  other  rules.  The  set  up  rules  have  a  lower  salience  value  but  are  only  fired  at 
program  start  up.  These  rules  are  cyclic  because  between  the  two  of  them  they  either 
assert  facts  that  cause  themselves  to  fire  again,  or  cause  rules  to  fire  that  in  turn 
cause  these  two  rules  to  fire  again.  These  rules  continue  this  cyclic  action  as  long  as 
there  are  no  incoming  messages. 

When  an  incoming  message  arrives,  one  of  the  iwo  previously  mentioned  rules 
asserts  a  fact  indicating  the  type  of  message  that  arrived.  Once  this  fact  is  asserted, 
one  of  four  message  handling  rules  reads  in  the  message  from  the  appropriate  I/O 
stream  and  updates  the  knowledge  base.  These  rules  are:  read-init-in,  read-update- 
in,  read-map-ready-in,  and  read-waypoint-in.  The  messages  read  in  are  as  follows: 

•  Vehicle  initialization  message 

•  Vehicle  update  message 

•  Search  map  ready  message 

•  Incoming  waypoint  message 

c.  Clock  Rules 

Each  vehicle  following  a  path  computed  by  the  path  planner  has  a  real 
time  clock  associated  with  it.  The  vehicle's  clock  is  initially  set  to  the  time  contained 
on  the  initialization  message.  This  is  done  via  the  set-clock  rule.  When  subsequent 
messages  contain  a  time  the  vehicle’s  dock  is  reset  to  the  message's  time  u.sing  '  “ 
reset-clock  rule.  If  no  messages  arrive  over  the  networks  the  vehicle's  clock  is 
updated  v>a  the  update-clock  rule.  This  last  rule  enables  the  path  planner  control 
program  to  calculate  a  projected  new  position  for  the  vehicle. 


d. 


cle  Monitoring  Rules 


When  a  message  arrives  carrying  vehicle  update  information,  the  up- 
date-vehicle  rule  modifies  that  vehicle’s  schema  to  reflect  the  new  location,  course, 
velocity,  time  and  guidance  mode.  If  no  message  arrives  to  update  the  vehicle's 
record,  the  update-clock  rule  gives  the  vehicle’s  delta-time  fact  a  value.  If  the  value 
of  the  vehicle’s  delta-time  fact  is  positive  the  change-po<Tir»n  rule  calculates  the 
distance  traveled,  updates  the  vehicle’s  location,  resets  the  vehicle’s  delta-time  fact 
to  0,  and  indicates  to  the  knowledge  base  that  the  vehicle  has  moved. 
e.  Vehicle  and  Waypoint  Control  Rules 

When  either  the  update-vehicle  rule  or  the  change-position  rule  fire, 
the  knowledge  base  is  updated  to  indicate  that  the  vehicle  has  moved.  This  change  to 
the  vehicle’s  schema  within  the  knowledge  base  fires  the  check-for-new-waypoint 
rule.  This  rule  calculates  the  vehicle's  current  distance  to  the  vehicle’s  current  way- 
point.  If  the  distance  to  this  waypoint  is  less  than  200  meters,  the  vehicle's  control 
schema  is  modified  with  the  fact,  (new- waypoint  yes).  When  the  knowledge  data¬ 
base  contains  the  control  schema  for  a  vehicle  with  the  fact,  (new-waypoint  yes),  the 
send-new-waypoint  rule  fires  sending  a  new  waypoint  to  the  vehicle  simulator.  In 
this  implementation,  every'  other  waypoint  is  skipped  to  mimic  more  closely  the  hu¬ 
man  commander’s  capability  of  skipping  over  100  meter  grid  squares  in  his  path  plan¬ 
ning. 

/.  Search  Control  Rules 

After  a  vehicle  has  been  initialized  in  the  path  planner  control  pro¬ 
gram’s  knowledge  base,  the  load-map  rule  is  fired.  This  rule  tells  the  search  control 
program  to  load  a  10  KM  by  10  KM  map,  with  the  specified  lower  left  hand  comer’s 
UTM  coordinates.  After  the  map  has  been  loaded  and  the  search  control  program 
sends  a  message  indicating  that  the  search  map  is  ready,  the  start-path  rule  fires. 
This  rule  gives  the  search  control  program  the  start  point,  goal  point,  and  the  vehi¬ 
cle's  ID. 
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g.  Fact  Clean  Up  Rules 

In  order  to  prevent  false  firing  of  rules,  used  facts  and  schemas  are 
cleaned  out  of  the  knowledge  base  whenever  possible.  The  clean-up-iris-msg  and 
clean-up-sym-msg  rules  clean  up  unclaimed  waiting  message  facts.  These  facts  are 
asserted  by  the  check-comm-links-iris  and  the  check-comm-links-sym  rules  when 
there  is  a  message  out  of  synchronization  or  spurious  characters  in  the  I/O  stream. 
The  clean-up-wavpoints  and  clean-up-vehicle  rules  are  fired  when  a  vehicle  goes 
out  of  guidance  mode  on  the  vehicle  simulator.  These  rules  remove  all  references  to 
the  vehicle  from  the  path  planner  control  program’s  knowledge  base.  This  ensures 
that  the  next  time  the  vehicle  requests  a  path,  an  old  path  is  not  given. 

2.  Search  Control  Program 

The  search  control  program  can  be  run  from  any  Symbolics  workstation,  ex¬ 
cept  SYN14  where  the  path  planner  control  program  resides.  The  search  control  pro¬ 
gram  directly  monitors  the  search  algorithm  and  keeps  track  of  which  vehicles  have 
maps  and  paths.  The  search  control  program  receives  two  types  of  messages  from  the 
path  planner  control  program.  The  first  message  requests  that  a  10  KM  by  10  KM 
search  map  be  loaded  into  a  map  array.  This  message  specifies  the  vehicle  nnd  the 
UTM  l.'om  the  low  er  left  hand  comer  of  the  10  KM  by  10  KM  area  to  be  searched.  The 
second  message  requests  that  an  optimal  path  be  found  from  the  start  to  the  goal. 
This  message  specifies  the  vehicle,  the  start  point's  UTM,  and  the  goal  point's  UTM. 
The  map-array  is  a  102  by  102  grid.  The  size  of  this  array  is  chosen  to  allow  a  search 
map  with  a  resolution  of  100  meter  squares  to  be  loaded  into  the  map-array,  including 
a  border  of  non-traversable  cells,  to  bound  the  search  algorithm. 
a.  Loading  tf 

When  a  message  is  received  that  requests  a  map  be  loaded,  the 
search  control  program  checks  to  see  if  that  map  has  ever  been  loaded  before.  This  is 
accomplished  by  first  converting  the  map  UTM  and  vehicle  ID  information,  contained 
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as  strings  in  the  message,  to  LISP  symbols  and  stored  in  veh-map  and  current-veh. 
The  *maps*  list  is  then  checked  to  see  if  the  newly  generated  map  symbol  is  on  the 
list.  If  the  symbol  is  on  the  list,  a  message  is  sent  to  the  path  planner  control 
program  indicating  that  the  map  is  loaded  and  ready  to  be  searched.  Alternatively  the 
search  control  program  builds  a  map-array  with  slope  data  from  the  data  file  used  by 
the  search  algorithm.  Finally,  the  symbol  value  of  veh-map  is  then  stored  to  the 
symbol  value  of  the  symbol  stored  in  current-veh.  The  symbol  value  of  current-veh  is 
then  added  to  the  list  *vehs*. 

b.  Searching  the  Map 

After  the  map  is  loaded,  the  search  control  program  receives  a  mes¬ 
sage  requesting  a  search  be  done  for  an  optimal  path.  The  message  received  contains 
the  vehicle’s  ID,  the  desired  path’s  start  and  goal  points  in  UTM  coordinates,  as  well 
as  the  map's  lower  left  hand  comer  UTM  coordinates.  The  UTM  coordinates  are  con¬ 
vened  to  coordinates  used  by  the  wavefront  search  algorithm.  The  wavefront  search 
algorithm  is  called  with  the  appropriate  map-array  selected  from  the  *vehs*  list.  The 
returned  list  of  points  is  converted  back  to  UTM  coordinates.  During  this  conversion  a 
random  number  generator  is  used  to  move  the  waypoints  around  inside  their  100 
meter  by  100  meter  grid.  This  is  done  to  simulate  the  commander's  selection  of  a  path 
from  a  low  resolution  map.  Since  the  goal  point  may  be  a  specific  point,  h  la  appended 
to  the  end  of  the  list.  Each  waypoint  is  also  tagged  with  the  requesting  vehicles  ID 
and  a  sequence  number.  The  sequence  number  is  used  by  the  path  planner  control  pro¬ 
gram  to  keep  track  of  waypoints. 

c.  Returning  Waypoints 

Waypoints  are  sent  to  the  path  planner  control  program  one  at  a  time 
for  each  path.  This  is  accomplished  through  the  send-way points  function.  The  function 
is  sent  the  list  *wave-paths*,  every'  time  the  search-controller  function  cycles 
through  its  do  loop.  This  list,  that  is  sent  to  the  send-waypoints  function,  contains,  as 
separate  lists,  the  remaining  waypoints  for  every  vehicle  that  has  reuuested  a  path. 
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Each  list  is  stripped  of  the  first  element,  and  this  element,  a  waypoint,  is  sent  to  the 
path  planner  control  program.  This  cycling  continues  until  all  of  the  waypoints  have 
been  transmitted. 

D,  SUMMARY 

This  chapter  contains  the  description  of  the  implementation  of  APS.  The  most 
salient  modules  and  structures  of  the  vehicle  simulator  are  described  with  specific  ex¬ 
planations  of  key  code  fragments  and  routines.  The  rules  and  control  flow  of  the  path 
planner  is  also  described  with  a  thumbnail  sketch  of  each  family  of  rules.  This  chapter 
explains  how  APS  works  while  the  following  chapter  describes  the  results  of  running 


V.  SIMULATION  RESULTS 


APS  achieves  a  large  part  of  its  research  goals.  A  platform,  depicted  with  a  fair 
degree  of  realism,  can  be  guided  along  a  path,  which  is  calculated  in  real-time,  to  its 
goal.  However,  direct  comparisons  of  human  and  machine  path  planning  are  not  pos¬ 
sible  due  to  a  bottleneck  in  communications  bitween  the  vehicle  simulator  and  ma¬ 
chine  path  planner.  Also,  due  to  time  constraints,  some  capabilities  were  not 
implemented.  The  most  important  shortfall  is  local  obstacles  and  obstacle  avoidance. 

A.  VEHICLE  SIMULATOR 

The  vehicle  simulator  achieves  all  the  design  capabilities  listed  in  Chapter  IV. 
Most  importantly,  it  is  able  to  support  navigation  of  a  platform  along  a  designated 
path,  under  various  combinations  of  manual  and  autonomous  control.  The  path  can  be 
designated  by  a  remote  human  commander  or  an  AI  machine.  The  remote  commander 
can  also  turn  the  platform’s  autopilot  and  external  guidance  controls  on  and  off,  even 
while  traversing  a  path  under  AI  agent  control. 

The  network  communications  supports  connected  multiple  vehicle  simulators 
with  real  time  interaction  supporting  command  and  control  and  combat  ''dogfighting" 
capabilities.  Simultaneous  control  of  multiple  platforms  by  different  sources  was  dem¬ 
onstrated  allow’ing  local  control  of  some  platforms  while  others  are  controlled  remote¬ 
ly  by  the  AI  agent. 

The  current  vehicle  simulator  drawing  cycle  speed  hovers  near  4  frames  a  sec¬ 
ond.  This  speed  produces  jerky  scene  changes  on  the  visual  display  and  makes  pre¬ 
cise  vehicle  control  difficult.  However,  it  remains  sufficiendy  realistic  to  support 
navigation  over  calculated  paths.  Run-time  analysis  indicates  that  steady  state  per¬ 
formance  is  bound  by  graphics  operations  and  not  computational  load1. 


CPU  utilization  was  with  the  CPU  wiling  predominately  for  graphics  calculations  or  drawing. 
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B.  PATH  PLANNER 

Two  key  research  goals  of  the  path  planner  w-ere  to  provide  an  easily  under¬ 
stood  interface  between  the  vehicle  simulation  and  the  path  planning  algorithm,  and  to 
provide  the  mechanism  for  easy  integration  of  search  algorithms  at  the  control  inter¬ 
face  level.  The  AI  path  planning  program  developed  for  this  thesis  has  been  tested  in 
real  rime.  The  path  planner  supports  the  major  goais  of  this  thesis.  It  provides  a  func¬ 
tional  interface  whereby  different  search  strategies  can  be  evaluated  and  tested 
against  a  human  planner.  The  AI  path  planner  provided  optimal  paths  for  the  driver  of 
the  simulated  vehicle,  using  a  w'avefront  search  algorithm. 

The  path  planner  spends  between  one  and  one  half  to  five  minutes  finding  an  op¬ 
timal  path.  After  the  path  is  found  the  path  planner  control  program  begins  returning 
waypoints.  The  issuance  of  waypoints  along  the  path  is  not  sufficiently  fast  enough  to 
compete  with  the  human  planner.  This  is  mainly  due  to  the  fact  that  the  human  plan¬ 
ner  issues  an  entire  path  to  the  vehicle  at  the  beginning  of  the  path,  while  the  AI  path 
planner  is  only  allowed  to  issue  one  waypoint  at  a  time.  The  AI  path  planner  must  ap¬ 
parently  wait  on  buffered  network  communications.  A  "work  around"  exists  to  force 
the  AI  path  planner  to  send  the  entire  path  as  soon  as  the  path  is  found.  This  howev¬ 
er,  would  remove  the  path  planner’s  ability  to  react  to  changes  in  the  terrain  as  the 
vehicle  travels  along  the  path. 

A  rule-based  path  planner  control  program,  written  in  ART.  controls  the  flow  of 
path  requests  and  the  issuance  of  waypoints.  More  than  one  simulated  vehicle  can  be 
guided  along  a  path  at  the  same  time.  The  path  planner  control  program  allows  multi¬ 
ple  vehicles  to  be  guided  as  long  as  each  has  a  unique  vehicle  ID. 

The  randomly  generated  offsets  to  the  waypoints  that  are  used  to  simulate  a 
human  path  planner’s  waypoint  selection  within  a  one  hundred  meter  square  grid  do 
not  adequately  simulate  the  way  a  human  path  planner  selects  waypoints  along  a 
path.  The  human  planner  generally  chooses  a  path  that  transitions  smoothly  from  grid 
to  grid,  except  where  demanded  by  terrain.  The  use  of  random  numbers  to  select  the 
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position  of  waypoints  within  the  designated  one  hundred  meter  squares  causes  these 
waypoints  to  be  unnaturally  placed  along  the  path.  This  can  cause  the  simulated 
vehicle  to  make  sharp  changes  in  direction  for  no  apparent  reason. 

The  skipping  of  waypoints  to  provide  a  more  reasonable  next  waypoint  for  the 
driver  only  appears  natural  in  terrain  that  is  typified  by  gradual  changes  in  slope. 
Where  the  terrain  changes  slope  frequendy  and  drastically,  the  skipping  of  waypoints 
can  cause  the  vehicle  to  traverse  areas  cf  extreme  high  cost.  This  occurs  when  the 
path  planner  has  planned  a  route  around  a  finger  of  a  hill,  but  the  waypoint  avoiding 
the  finger  is  skipped. 

C.  COMBINED  SYSTEM 

Obstacles,  obstacle  avoidance  and  local  path  planning  were  not  implemented. 
Therefore,  path  transit  time  was  purely  c  function  of  vehicle  speed  and  an  actual  opti¬ 
mal  path  directly  calculable  from  the  global  terrain  data. 

Several  trials  were  run  over  identical  routes  (2-7  KM  long)  under  human  and  AI 
agent  path  planning.  Human  path  planning  is  relatively  quick  and  accurate  when  there 
is  distinctive  terrain  such  as  steep  hills  and  flat  valleys;  that  is,  when  the  best  route 
is  fairly  obvious.  When  terrain  is  mixed  and  the  trade-off  between  going  straight  over 
steeper  terrain  or  making  a  detour  is  more  subtle,  the  visual  decision  becomes  more 
difficult. 

Since  there  were  no  obstacles,  most  trials  were  run  vrith  the  autopilot.  The  au¬ 
topilot  always  tries  to  maintain  maximum  speed,  so  a  correctly  calculated  optimal 
path  traversed  on  autopilot  should  result  in  a  minimum  transit  time.  Unfortunately,  di¬ 
rect  comparison  between  human  and  AI  agent  planned  paths  was  not  possible  due  to 
the  inability  of  the  Symbolics  system  to  keep  up  with  the  vehicle  simulatoi.  Instead 
of  the  AI  agent  updating  guide  points  when  the  vehicle  was  within  200  meters,  so 
that  there  would  be  no  break  in  speed,  the  vehicle  would  often  reach  a  guide  point  and 
come  to  a  stop  before  receiving  the  next  guide  point.  When  such  a  delayed  guide 
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point  was  received,  an  additional  time  penalty  was  incurred  as  the  vehicle  simulator 
accelerated  up  to  the  maximum  speed  allowed  by  the  terrain.  As  a  result  of  this  delay 
in  receiving  new  guide  points,  transit  times  under  the  Symbolics  AI  agent  control 
were  2-3  times  longer  than  transit  times  for  human  planned  paths.  Consideration 
was  given  to  working  around  this  problem  by  having  the  Al  agent  send  the  entire  path 
once  calculated.  However,  this  w-ould  eliminate  the  capability  for  the  AI  agent  to  dy¬ 
namically  modify  the  path,  based  on  obstacles  or  other  detours,  so  this  option  was  re¬ 
jected. 
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VI.  SUMMARY  AND  CONCLUSIONS 


A.  LIMITATIONS 

1.  Vehicle  Simulator 

The  APS  vehicle  simulator  is  currently  limited  in  the  following  ways: 

•  Applies  only  to  tactical  vehicles  travelling  off-road. 

•  Models  single  gear  transmission  vehicle  for  acceleration. 

•  Operates  in  a  single  terrain  database. 

•  Has  simplified  vehicle-terrain  interaction  model. 

•  Simulates  joystick  driving  controls  with  a  mouse. 

There  are  some  features  of  the  vehicle  simulator  that  don't  work  correctly 

or  fail  to  work  under  certain  special  circumstances.  A  list  of  such  features,  the  nature 
of  the  fault  and  all  other  known  bugs  is  contained  in  Appendix  D. 

2.  Path  Planner 

The  AI  path  planner  is  currently  limited  in  the  following  ways: 

•  The  path  planner  does  not  take  into  account  local  obi  ade  avoidance. 

•  A  vehicle  can  be  run  on  an  AI  generated  path  only  c  '  :e. 

•  Only  one  Symbolics  workstation  is  available  to  run  the  path  planner  control 
program  written  in  ART. 

•  The  terrain  slope  data  file  must  be  preprocessed  into  the  correct  format. 

•  The  planned  path  is  limited  within  a  ten  kilometer  region. 

B.  AREAS  FOR  FURTHER  STUDY 

The  most  pressing  need  for  further  development  is  to  remove  the  bottleneck  at 
the  AI  agent  end  of  the  communications  and  to  add  obstacles  and  obstacle  avoidance. 
Breaking  the  path  planner’s  message  processing  logjam  would  allow  direct 
comparisons  between  the  actual  transit  time  of  human  and  machine  planned  paths,  a 
major  goal  of  this  research.  Obstacles  w'ould  add  the  global-local  dimension  to 
functional  assignment  trade-offs  between  human  and  machine  planners,  another 
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unexplored  area.  Other  areas  for  further  study  lie  in  increased  realism  and  added 
functionality  for  the  vehicle  simulator  with  multiple  algorithms  the  focus  for  the  path 
planner. 

3.  Vehicle  Simulator 

The  most  fruitful  areas  for  further  study  of  the  vehicle  simulator  are  simula¬ 
tor  realism,  graphics  performance,  local  autonomous  operations,  and  program  struc¬ 
ture/software  engineering  issues. 

a.  Program  Structure  /  Software  Engineering 

The  vehicle  Simulator  program  consists  of  =37,000  lines  of  source 
code  in  238  files.  About  7500  lines  are  pure  drawing  code,  that  is.  polygons  and  fig¬ 
ures.  The  majority  of  the  source  files  contain  a  single  function.  This  flat  program 
structure  in  such  a  large  program  doesn’t  provide  the  modularity  or  encapsulation  nec¬ 
essary'  to  manage  the  rapid  modification  and  maintenance  necessary  in  a  system  sub¬ 
ject  to  the  constant  flux  of  research.  For  example,  to  add  a  new  platform  type  say  an 
Armored  Personnel  Carrier  (APC),  would  necessitate  modifying  more  than  20  files, 
even  if  its  graphical  object  definition,  material  definitions,  and  vehicle  characteristics 
were  already  available.  A  requirement  to  modify  the  platform  modeling  or  control  for 
this  new  \r’  >cle  type  would  entail  even  more  extensive  and  treacherous  changes. 

An  Object  Oriented  Programming  (OOP)  Language  would  provide  an 
order  of  magnitude  simplification  of  the  program  structure  and  code.  Encapsulation 
would  limit  the  effects  of  code  modifications  reducing  debugging  and  retesting  of  work¬ 
ing  components  ensure  the  containment  of  side  effects.  Inheritance  would  eliminate 
duplicating  code  that  performs  essentially  the  same  thing  but  in  slightly  varying 
ways.  For  example,  this  would  allow  each  platform  to  be  an  instantiation  of  a  general 
class  containing  methods  for  control,  modeling,  and  display.  These  methods  would 
then  operate  on  class  and  local  data  structures  to  provide  the  required  function. 
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Since  the  vehicle  simulator  is  written  in  C  and  currently  C  seems  to 
have  the  most  thorough  and  efficient  interface  to  the  SGI  graphics  library,  a  C  based 
OOP  language  such  as  C++  or  ObjectiveC  would  be  appropriate  candidates  for  such  a 
conversion,  with  a  low  risk  that  performance  penalties  might  eliminate  its  advantages. 

Another  alternative  is  Ada.  Encapsulation  and  inheritance  can  also 
be  implemented  through  Ada  "packages".  In  addition  Ada  is  expressive  enough  to 
serve  as  a  program  design  language  (PDL)  and  is,  after  all,  the  DoD  "standard"  lan¬ 
guage. 

b.  Realism 

Current  research  at  NPS  has  produced  some  capabilities  that  could 
enhance  realism  without  a  large  performance  penalty.  The  realism  of  the  3D  depiction 
of  terrain  can  be  improved  by  increasing  the  resolution  of  the  terrain  data.  This 
shrinks  the  size  of  the  near  view  terrain  polygons  making  them  seem  more  natural.  In 
addition,  the  terrain  display  could  be  made  more  realistic  by  adding  "features"  such  as 
roads,  structures,  lakes,  and  vegetation.  Winn  and  Strong  [WINN&89]  have  demon¬ 
strated  a  terrain  drawing  system  that,  utilizing  IRIS  hardware  support,  increases  the 
terrain  resolution,  helps  realism  through  better  shading  techniques  and  boosts  perfor¬ 
mance.  They  also  developed  a  real-time  line-of-sight  system  that  could  be  useful  as 
a  alternative  or  additional  cost  function  for  path  planning.  Adoption  of  a  standard 
graphical  object  definition  language  such  as  Fixar’s  Renderman  or  Object  File  Format 
(OFF),  the  language  developed  at  NPS  [MUNSON89]  would  create  access  to  a 
large  library  of  realistic  images  of  platforms  and  other  objects. 

Vehicle  realism  could  be  enhanced  by  including  the  following  features: 

•  Multiple  gear  transmissions. 

•  Realistic  slope  effects. 

•  Sound. 

•  Different  model  constants  by  vehicle  type. 

•  Adding  vehicle  stability  effects;  i.e. ,  turn  over  or  crash. 

•  EnergyTuel  consumption. 
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c.  Increased  Capability 

APS  is  Cuirently  limited  to  preprocessed  terrain  data  for  one  35 
square  kilometer  area  of  the  world.  Drummond  and  Nizolak  [MZOLK&89]  in  HOST 
modified  the  original  MPS  terrain  representation  system  to  accept  standard  format 
DTED  files,  available  for  many  parts  of  the  world. 

Additional  path  planning  cost  functions,  such  as  exposure  to  enemy 
observation,  energy  or  fuel  consumption,  tactical  maneuver  advantage,  etc.,  could  be 
used  as  alternate  or  combined  figures  of  merit  to  evaluate  the  quality  of  the  product  of 
the  path  planner  in  differing  environments. 

The  trafficability  model  could  be  expanded  from  a  s;mple  function  of 
slope  magnitude  to  consider  soil  conditions,  vehicle  traction,  and  anisotropic  slope  ef¬ 
fects  such  as  those  contained  in  the  vehicle-terrain  interaction  model  of  Ross 
[ROSS89], 

The  unimplemented  simulated  vision  system,  planned  to  provide  in¬ 
put  on  local  conditions  to  the  obstacle  avoidance  system,  was  modeled  after  the  laser 
terrain  scanning  system  of  the  Adaptive  Suspension  Vehicle  [BIHAR1&89:  pg  61]. 
There  is  an  interesting  interaction  between  the  range  and  resolution  of  the  vision  sys¬ 
tem,  the  speed  of  the  obstacle  avoidance  process  and  the  maximum  safe  speed  of  the 
vehicle.  Simply  put.  the  vehicle  cannot  safely  go  faster  than  its  sensing  and  naviga¬ 
tion  system  can  react  and  respond.  Were  local  obstacles  and  obstacle  avoidance  im¬ 
plemented,  this  simulator  could  be  used  to  compare  the  overall  performance  of  vision 
systems  by  varying  the  sensing  system  parameters:  range,  resolution,  fidd-of-view, 
and  speed;  and  then  navigating  real  terrain. 

d.  Performance 

Vehicle  performance  in  terms  of  frames  per  second  is  of  concern  in  the 
vehicle  simulator  only  insofar  as  it  effects  realism.  Other  researchers  at  NPS  have 
looked  specifically  at  performance  and  found  no  magic  algorithm  that  promises  orders 
of  magnitude  improvement  due  to  sof'uare  changes  [FICHTN&8S|.  Th.  *  does  not 


mean  that  performance  comparisons  are  unimportant  or  that  efficiency  can  be  ignored, 
simply  that  performance  is  not  directly  germane  to  this  research. 

4.  Path  Planner 

Two  key  research  goals  of  the  path  planner  used  in  this  thesis  were  first, 
to  provide  an  easily  understood  interface  between  the  vehicle  simulation  and  the  path 
planning  algorithm,  and  to  provide  the  mechanism  whereby  search  algorithms  could  be 
easily  interchanged  at  the  control  interface  level.  This  implementation  of  the  path 
planner  is  a  prototype  that  needs  to  be  refined  and  expanded.  Aieas  of  research  that 
would  provide  significant  improvements  on  this  study  are  as  follows: 

•  Incremental  route  planning 

•  Selection  of  route  planning  algorithms  depending  on  requirements 

•  Comparisons  of  expert  system  shells 

•  Comparisons  of  search  algorithms  using  real  terrain  data  and  simulated  vehi¬ 
cles 

•  Improved  communications 

a.  Search  Algorithms 

The  wavefront  search  algorithm  used  in  this  study  is  well  understood 
and  provides  a  standard  by  which  other  search  algorithms  can  be  judged.  There  are 
many  other  algorithms  available  that  provide  capabilities  unique  to  each.  The  decision 
to  use  a  particular  search  algorithm  may  be  based  on  the  constraints  of  the  path  and 
mission.  An  area  for  further  study  is  to  select  appropriate  search  algorithms,  depen¬ 
dent  on  the  terrain  and  mission  to  be  planned.  Another  area  of  study  is  the  use  of  a 
preprocessing  algorithm  that  would  allow'  the  vehicle  to  start  along  the  path  before 
the  path  is  completed  and  still  get  reasonable  results. 

b.  Expert  System  Shells 

The  path  planner  was  implemented  in  ART  which  provides  a  high  lev¬ 
el  symbolic  programming  environment  that  allows  predicate  representation  of  rules. 
This  representation  allows  the  path  planner  written  in  ART  to  be  understood  by  any- 
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one  who  has  a  grasp  of  predicate  logic.  ART  however  is  not  currently  supported  on 
the  next  generation  of  Symbolics  workstations,  nor  is  ART  code  easily  converted  to 
some  common  language  and  then  transported  to  some  other  LISP  machine.  This  last 
area  of  research  is  particularly  interesting  as  graphics  machines  are  beginning  to  in¬ 
cot  porate  LISP  processors  as  an  integral  part  of  the  architecture, 
c.  Communications 

The  path  planner  has  not  been  able  to  keep  up  with  the  vehicle  simu¬ 
lation.  There  appears  to  be  a  problem  with  the  buffering  of  messages  in  the  Symbolics 
workstations.  The  path  planner  could  also  be  improved  by  the  addition  of  algorithms 
that  would  check  for  the  most  recent  update  message  instead  of  filtering  down 
through  the  messages  that  have  arrived  and  backed  up  in  the  buffer. 

C.  SUMMARY 

APS  provides  a  testbed  for  the  study  of  real-time  path  planning  and  control 
strategies  and  algorithms  without  the  cost  of  building  actual  hardware.  It  serves  as  a 
bridge  between  the  theoretical  study  of  a  simplified  abstract  problem  to  applied  re¬ 
search  producing  concrete  performance  under  realistic  conditions.  The  conclusions  of 
this  study  show  the  feasibility  and  advantages  of  such  as  system  in  settling  perfor¬ 
mance  debates  with  empirical  results. 
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APPENDIX  A.  VEHICLE  SIMULATOR  MODULE  DESCRIPTIONS 

A.  DATA  DESCRIPTIONS 

Data  structure  definitions  and  program  constants  are  contained  in  C  "header 
files"  which  normally  have  an  ”h"  suffix.  A  list  of  all  APS  header  files  is  contained  in 
Table  A-l.  The  main  data  structures  used  in  APS  are  contained  in  "aps.h"  (Figure  A- 
1)  and  "weapons. h"  (Figure  A-2).  Global  variable  declarations  are  contained  in 
"global. h"  which  is  included  at  compile  time  in  the  APS  main  module  "aps.c". 

B.  MODULE  ORGANIZATION  AND  PROGRAM  CONTROL  FLOW 

The  top  level  APS  function  main()  (Figure  A-3)  is  contained  in  the  file  "aps.c". 
This  module  initializes  the  system,  mns  the  simulator  by  calling  event().  and  cleans 
up  during  program  termination.  Module  event()  (Figure  A-4)  initializes  the 
simulator,  displays  introductory  screens,  gets  a  user  selection  of  a  10  Kilometer  area 
to  work  in,  handles  dne  main  u.enu  selections  and  calls  either  of  the  two  main  drawing 
loops:  event_driving()  (Figure  A-5)  or  event_tlying()  (Figure  A-6).  If  the  user 
selects  RETURN  TO  MAIN  MENU  from  the  driving  menu  or  the  platform  he  is 
operating  is  destroyed,  control  returns  to  event(),  the  10  Kilometer  2D  map  is 
displayed,  and  the  main  menu  is  presented  to  renew  the  cycle.  If  the  user  selects 
EXIT  THE  PROGRAM  from  the  driving  menu  control  then  the  program  is  terminated 
by  returning  control  through  eventQ  to  ma!n().  The  remaining  modules  contain 
functions  which  are  either  sub-packages  under  one  of  the  main  routines  or  general 
support  functions  that  are  called  to  do  some  task  from  *>C  vcldi  jpitlCCS.  1  HlaC 
modules,  the  functions  contained  in  each  one,  and  a  brief  description  of  what  they  do 
are  listed  in  Table  A-2. 
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TABLE  A-i  APS  HEADER  FILES 


aps.h 

Main  global  data  structures  and  constants. 

Cobra_data.h 

Cobra  object  data. 

Cobra_ins  ide_pt  .h 

Object  data  for  Cobra  inside  view. 

coior_scheme.h 

Program  RGB  color  array  indexes. 

controls. h 

Constants  for  controls. 

event_status.h 

Main  loop  state  definitions 

files.h 

System  data  file  names 

flamedata.h 

Object  data  for  wreck  'burning  jeep  flames). 

global. h 

Global  variable  declarations. 

gundata.h 

Tank  main  gun  object  data. 

jeepdata.h 

Jeep  object  data. 

legend. h 

Positioning  constants  for  legend  windows 

lightcons.h 

Materia]  definition  constants. 

lightdefs.h 

Lightuig  array  declarations. 

macros. h 

Copy  of  system  header  file  that  defines  C 
macros  without  bug. 

Main_rotor_data.h 

Object  data  for  Cobra  main  rotor 

math_utility.h 

Math_utility  function  prototypes. 

missiledata  h 

FOGM  object  data. 

Mrotor_inside_pt.h 

Object  data  for  tip  of  main  rotor  seen  from 

inside  Cobra  cockt 

network. h 

Network  message  dci.  ters,  types  and 

formats. 

TABLE  A-l  APS  HEADER  FILES  -  CONTINUED 


network_services.h 

Network  function  prototypes. 

openjeepdata.h 

Open  jeep  object  data. 

pathdata.h 

Path  data  structures  definitions. 

pathfunc  h 

Path  function  prototypes. 

popups.h 

Popup  menu  names  and  return  values. 

rollerdata.h 

Tank  roadwheel  object  data. 

Rotdat.h 

Cobra  rotor  rotation  rates. 

Tail_pipe_data.h 

Cobra  IR  suppressor  object  data. 

Tail_rotor_data.h 

Cobra  tail  rotor  object  data. 

tankdata  h 

Tank  object  data. 

terrain.h 

Terrain  3D  display  constants. 

tiredata.h 

\Vheeied  vehicle  tire  object  data. 

Tpipe_inside_pt.h 

Cobra  1R  suppressor  object  data. 

trackdata.h 

Tank  track  object  data. 

trackdata2.fi 

More  tank  track  object  data. 

Trotor_inside_pt.h 

Cobra  tail  rotor  data. 

truckdata.h 

Truck  object  data. 

turitdata.h 

Tank  turret  object  data. 

vehmodel.h 

Platform  motion  modeling  constants. 

weapons,  h 

Weapons  system  data  structures  and 

constants. 
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♦include  "gl.h" 

♦include  "fmclient.h"  .  *  inherit  font  manager  definitions  * 
♦include  "pathdata.h" 

/*  pathdata.h  required  because  there  are  ptrs  to  paths  in  Vehicle 
data  structure. 

*/ 

♦xfndef  NULL 

♦define  NULL  0 

♦endif 

defines  for  manipulating  the  terrain  data  file  * 

♦define  ELEV  MASK  Oxlfff 

♦  define  F.D  0 

♦  define  WP.  1 

*  defines 
♦define  X 
♦define  Y 
♦define  2 
♦define  L 
♦define  V 

*  defines  for  polygon  orientation  * 

♦  define  MAXCCOPL'S  80 

♦define  MAXLOOKDI STF  32908.0 

/*  define  maximum  size  for  pickbuffer  * 

#de  fine  F  ICK_BUFFEP._SI  ZE  512 

/*  define  default  range  for  rangefinder  */ 

♦define  RANGE  DEFAULT  9999 


Figure  A-l  APS.H  Main  Header  File 


for  polygon  computations  * 
C  .  *  X  coordinate  * 

1  ,  *  Y 

2  f*  2 

0  LOWER  triangle  * 

1  *  UFFEF,  triangle  * 
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defines  for  conversions 


★  / 


#def ine 

TO_MPS 

0 .44703 

♦define 

FEET  TO  METERS 

0.3048 

/*  defin 

es  for  useful  constants  * 

♦define 

TENTHKM 

100 . 0 

♦define 

TWOTENTHKM 

200 

♦define 

HALFKM 

500.0 

♦define 

ONEKM 

1000.0 

♦  def ine 

TWO  KM 

2000.0 

♦define 

TEHKM 

10000 . 0 

#de  tme 

MAXI. _  OKo  ST 

5  9  4  2.6 

♦define 

MAXELEV 

1134 

♦define 

MINELEV 

o 

♦define 

NUMXGRIDS 

100 

♦  de  fine 

NOME GRIDS 

!  00 

♦define 

X  DATA_PTS 

101 

♦de fine 

2  DATA__FTS 

101 

♦  de  fine 

TANKGNDHT 

1.6612 

#de  fine 

TRUCKGNDHT 

1 . 6764 

♦define 

JEEFGNDHT 

0 .665" 

♦  de  fine 

OF  EN JEEPGNDHT 

0.655"" 

♦define 

TOWGNDHT 

1  .  V 

♦define 

ATKHELHT 

1  .  0 

♦define 

MAXYEH 

999 

'  '  Maximum  numb 

e r  c  f  LOC 

♦define 

MAXYEH  NUMB ITS 

10 

/*  Number  of  bits  to  shi 

ids  *  / 

♦define 

VEHID  MASK 

OxFFFFF 

/*  Mask  to  yet 

positive 

♦define 

MAXDE FAULTS 

9 

♦define 

FOGM  INIT  HT 

50.0 

.  VJ 

,*  5  94  3.6  meters  —  1950'?  feet 
, '  *  113  4  meters  =  3  ~  2  0  feet 
*  0  meters  =  0  feet  * 


AL  platforms  allowed  * 

ft  host  id  to  make  room  for  MAXYEH 

local  base  platform  id  */ 


Figure  A-l  APS.H  Main  Header  File  -  Continued 


V4 
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#def  ine  TOW\rEH  6 

♦define  ATKHEL  7 

/*  upper  limit  on  weapon  types  per  platform  *, 
♦define  MAXWEAPONS  2 

♦define  MAX  RDTYPES  PER  WEAPON  2 


/*  defines  for  the  arrows  drawn  on  the 
♦define  ARROW_LENGTH  30.0 

♦define  ARROW_WING_LENGTH  10.0 

♦define  ARROW  WING  ANGLE  25.0 


2D  terrain  map 


defines  for  window  ids  * 


♦  define  B I  LLBOAF.I'WIN  0 

♦define  MAF WIN  1 

♦define  MENUWIN  2 

♦define  NAVWIN  3 

» define  INDWIN  4 


*  'overdraw  color  defines  * . 

♦define  "LEAP OVERDRAW  0 

♦  define  BLACKOVEP.DRAW  1 

♦define  REDOVERDRAW  2 

♦  define  BLT,EOVEFX'FAW  3 


defines  for  networking  * 

♦ define  FA:k.ET_SIZE  512 

-*»*#**  Data  type  definitions 
typedef  float  time_f;  /*  time,  in  floating  point  seconds 


/*  enumerated  variable  to  indicate  which  viewing  mode  driven  ve 
is  in  */ 

typedef  enum  (  normal_view  =  0, 

driver, 

binoculars, 

wpn_sight  }  View_mcdes  ; 


Figure  A-l  APS.H  Main  Header  File  -  Continued 


hide 
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,  *  Def:  -numerated  type  for  global  vai  iafcle  tv  mil  -a*:e 

plat  :  : m  control  m.de . 

* 

typedef  enum  (  MANUAL  =  0, 

AUTOPILOT  I  Cent  r  o 1 _t ype ; 


typedef  enum  (  LOCAL  -  0,  NET  )  Vehowner; 


■o  rni  p.  e  f  p  1  a  t  f  r  m , 
1  .  ■  r  a  1  ■  r  net  w  i  k  . 


typedef  enum  (  OFF  =  0,  ON  I  T  ."j  jle;  *  Indurates  whe*  her 

?-'.m<“thin-3  is  - n  •  r  ft. 

,  *  type  definitions  f.r  [.  lat  form  data  sUu  yi**  * 
typedef  struct  vehicle  f 

mt  net_id:  *  f  LATFOPM  II  N'.'MEEF  FT-  NETW  .  PK I  ■'  F'Tf 

short  pick_l  -Jr  *  F  L’K  IP  N"MFF.F  F ■'  F  TAP  1FTII10  5  .op;:-:  * 

Vehowner  owner:  *  indi  rates  whether  platfrim  is  1  -al  :  n«t 


YF  ‘ 


.  nt  : 


View_m  •  1*3  "iew_m--ie;  *  Ini:  a‘-s  !e?::»  1  ••  i  ®w  fr  rr  -»hi  4 *  * 
Toggle  e::t_guidance .•  *  Indicates  whether  external  gui  dan  -e 

i?  rtl  i  FF. 


Toggle 

ro  -  •" 

F  at  h  ; 

*  I.'j  i:  rates  wh° * 

her  ir 

.•  :r  i  r:  j: :  >»:  * 

p  h  ~  ■ ;  L  i  b  ^  3  i  1 

-1 

C»  "  T  C!  ♦-  •  j  a  f  *-  j~. 

Eooi »3n 

i 

up  da*-  : 

*  FU.J  i  n  1  i  ’  q  t  i : 

J  v;  h  «=>  t 

H  *-  <  j  *  <  ►  O  <!  h_ 

[  o  S  ^  !1 1  -  ’it  V 

ei  n  e t. 

w  _  r  k  f  r  this 

}  ■  ]  a  f  r  m  . 

s  h  a  r  t 

t  ; 

/*  FL 

AY FORM  TYFE  * 

Coord 

x; 

'*  X 

TRANSLATION  * 

Coord 

y  ■ 

,  *  Y 

TRANSLATION  * 

Coord 

z  ; 

/'*  z 

TRANSLATION  */ 

double 

utm  x. 

utm  y  ; 

/  *  UTM 

Coordinates  of  platform  t 

0  meter  * 

f  loat 

cs e  ; 

,  *  veh 

heading,  (rotation 

about 

Y  axis) 

from  positive  X-axis,  in  radians.  Must 
be  converted  to  compass  degrees  for  I' 


Figure  A-I  APS.H  Main  Header  File  -  Continued 


91 


Figure  A-l  APS.H  Main  Header  File  -  Continued 
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extern 

float 

calc  distance!  Coord  xl,  Cocrd 

yl.  Coord  zl 

Coord  x2.  Coord 

y2.  Coord  zi 

extern 

void 

center  string  map (  char  *str,  1 

ong  liner.un 

extern 

void 

center  string  menu!  char  *str. 

long  linenum 

extern 

float 

compass  degrees  to  radian  angle 

(  float  deg 

extern 

float 

convert  to  dec  hr () ; 

extern 

short 

convert  to  hr  rain () ; 

extern 

t  ime  f 

elapsed  time  wreset (void) ; 

extern 

Vehicle 

‘find  platform;  int  netid  ); 

*  in 

check  f 

or  packets  . 

c  V 

extern 

float 

and  level (  Coord  x.  Coord  z  ) ; 

extern 

me  u  s  e  s  c  r  e  e 

ntoutmf  short  sx,  short  sy. 

double  *utmx,  double  *utm 

y  f 

extern 

rn  ~  '  ■  3  ^ ’  t  m^-  c 

screen;  double  utmx,  double  utrn.y. 

short  *sx,  short  *sy, 

she  rt  win  i-vw )  ; 

e  x.  t  e  -  r*. 

rr.c  u  s  e  c  t  rv.t  ^ 

•-  D  ^  ’  fl  1  "1  •  J  b-  1  O  ||‘  "  ••  •  1  V-  1 

,  f  1  .  a  \ 

*  -  -  1  ; 

c*  -•  *-  *u.  r  *  ' 

T".  \  ;fp’  o»r  : 

1  I'j t  ut  ITi  l  £  \  2  3 1  b  "  f  t  _  ^ *-  f-  — 

ie  :! 

*utm.y)  ; 

extern 

fl  .  at 

radian  angle  t_  compass  degrees 

i  flea*,  angi' 

*=>-•*-  or  r-\ 

t  r.T.e  i 

res  j  s imt imer  (  '  ; 

extern 

f  I a  t 

restrict  an  j!°  :  first  rev:  lut 

i:n  (  f  1 .  =i t  a : 

.  *  radians 

only  * 

p;;*;  c»  ^ 

f  1  ■  a* 

sinocs l  float  anile,  floaf  ‘cos 

ine  '  ; 

O  r-  r} 

Vehicle 

*  s  w  i  t  c  h  v  e  h  t  >  ; 

<c>  *-  •- 

-ho  it 

tet  room  ground  veh  i  I  : 

e  n  ter  n 

she.  1 1 

tot  num  veh  (  )  : 

extern 

dour  ie 

veodotp  ; )  ; 

exte  r n 

doufc ie 

veemag ( ) 

*  dec 

1 a r e  very 

coinmon  global  variables  */ 

extern 

Vehicle 

‘vehlist,  *vehlister.d,  ‘driven 

extern 

Boolean 

networking; 

extern 

int 

color  scheme  index; 

Figure  A-l  APS.H  Main  Header  File  -  Continued 
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extern  int  rrui.dance_si.gnal  ; 

extern  float  eye  posit ion [ NVMYEHTiFES ] [ ? ] ; 

,'■*  offset  of  eye  from  center  cf  veh  V 
extern  long  centerx,  centery;  .  *  srreen  coord  of  center  of  MAP'.vlH  */ 
extern  Boolean  ccntrol_ccr.nected; /*  flag  indicating  remote  process  is 

connected  to  server . 


/*  Font  handles  -  Initialized  in  mitiris  *, 

extern  fmfonthandle  Helv,  HelvB,  TimesPm,  TimesRmB; 

extern  fmfonthandle  scaled_Time sRm,  scaled  TimesFmE, 

scaled_Helv,  scaled  HelvB; 

/  *  Make  UTM  coordinates  of  lower  left  corner  of  10  KM  t'::  alobal 
extern  double  LL  tenkmutm  LL  tenkmutm 

IF.  tenkmutm  ,  7P.  tenkmutm  y; 

*  r cord  cf  Lowe r  lefc  cf  zccrneil  tci i  * 
extern  double  zoomed  LL  x,  to  -me i  LI  v; 
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Figure  A-2  WEAPONS  Header  File 


♦define 

BINCS 

i. 

tdefme 

TOW 

3 

♦define 

DRAGON 

4 

♦define 

IFV_SBT 

5 

♦define 

IFV_HEI 

6 

fueiine 

IFV_TOW 

7 

♦define 

COBRA  TOW 

8 

♦define 

COBRA  20MM 

9 

#de  fine 

APACHE  HF 

10 

♦define 

AFACHE  25 

11 

#  de fine 

TANKFIFE  IN 

TER7AL  6.0 

*  Reload  t 

ime  for  generic  tank  system  * 

.  *  be  £  i 

ne  F  _’V  and  A3 

EFCT  to  set  perspective  when  de 

pick 

ing .  *  1 

♦define 

PG'.’ND  F'jV 

3 

.3  degrees  or  6  mils  * 

ip.® 

rc’:ni?_asfec 

T  0.8 

♦define 

SFLASH_DURATION  4.0 

*  How  long  tc  displ ay  target  miss  ground 

#  de  £  1 ne 

FIRING  TFL 

INC  100.0 

*  Range  in 

crements  in  firing  tables  * 

♦  de  f i ne 

FIRING  TEL 

LENGTH  10 

'*  Number  of  entries  in  ballistic  tables 


t yr  ede  f 

struct 

wc  r Id ccor d 

2D  { 

float  ::,y;  1 

WCOOPD2 : 

typedef 

struct 

wor 1 d coord 

3D  ( 

float  y,z; 

)  WCOOF.I 

typedef 

st  ruct 

screencocrd  ( 

short  ::,y;  } 

7C0CF.D  ; 

typede  f 

short 

Colorvector 

S  l  3  ]  ; 

typedef 

long 

Colorvector 

L  [  3  ]  ; 

typedef 

float 

Colorvector 

F  [  3  }  ; 
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Define  record  for  class  of  araiu"  j  t  ion  or  type  of  rourv: 


trajectory  type  (  EN'JM  ) 


warhead  (  ENUM  ) 


round  name  (  STRING [10]  ) 


speed  (  meters. sec  ) 


minrange  <  meters  ) 


maxrar.ae  [  meters  ) 


type Jef  enum  gdtype  .  PALLI GTI : ,  GUIf ED _L0S  I  TYFE_r LIGHT 

typedef  enum  ammo_type  (  INERT,  CHEMICAL,  NUKE,  FASCAM, 

SUBMVNITION  '  TVF  E_WAF  HEAD  : 
typedef  struct  munition  type  I 


":FE  FLIGHI 


iectory  typ< 


TYPE  WARHEAD  warhead: 


f  1  c  a  t 
float 


float 


r cun J_name [ 1 0 } ; 
speed; 


mmranqe  , 


maxrange ; 


*■  type  of  traiertory  * 

*  type  of  warhead  * 

*  string  name  of  munitiin 

*  jxi 0 0 17 s  second  * 

*  minimum  arming  range  * 

*  maximum  effective  rar.ae 


ball is tic  t able [11]; 


)  MUNITION  CLASS;; 


Define  structure  for  sight  reticle 


Figure  A-2  WEAPONS  Header  File  -  Continued 


type 


name  -  STRING 


magnificat  ion 


numlines  -  #  lines  in 


lines  — >  HAIRLINE  (array) 


safe  liqht 


range_posn  (  pesn  of  range  string  ) 


round  posn  (  posn  of  round  string  ' 


typedef  int  CHAR_F  CSN  [  2  )  ;  *  ,  y  tuple  defines  crigm  .  f  te:T 

/*  Lower  left  and  upper  right,  dimensions  of  a  re  rtangle  * 
typedef  struct  rect_type_2I  f 

float  11  11  y,  ur  ur  y; 


}  RECTANGLE2D; 

typedef  struct  hair line_record  ( 
float  start  [2],  end [2; 
I  HAIRLINE;; 

typedef  struct  reticle  record  ( 


reticle  hairline  start  -  end 


int  type; 
char  name [10]  ; 
short  magnification; 
int  numlines; 

HAIRLINE  *  lines; 
RECTANGLE 2D  safe_liqht; 
CHAR_POSN  range_posn; 
CHAR_POSN  round_posn; 
)  RETICLE; 


,  *  code  for  type  of  reticle  * 

,  *  string  containing  weapon  reticle  name 
/*  normal  magnification  cf  siaht  * 
i *  count  of  number  of  hairlines  in  reticle 
/*  pointer  to  any  array  of  HAIRLINE 
/ *  rectangle  coordinates  for  safety  liaht 
/*  origin  of  range  string  */ 

/*  origin  of  round  name  string  */ 
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Define  structure  to  represent  fired  round  while  in  flight 


typedef  struct  Rif 

types  1 

WCOCRD3 

fire  posn. 

/*  locatijr  of  platform  when 

round  13  fired.  * 

posn, 

/*  location  at  last  update  */ 

pt  of  aim; 

/*  world  coord  pt  of  aim  */ 

float 

f ired_range 

,  *  range  data  used  when  fired  * / 

fired  di st ; 

/*  current  distance  from  pt  wher 

f i red  * 

f  loat 

angle , 

*5 1  *?  v ; 

’/  >  j  £• 

*  fiie i  ; 

*  pt  r  t  .  j.  la*  f.im  that  firel 

t  he  1  ■  ur. :! *  . 

MUNITION  CLASS 

}  ROUND  IN  FLIGHT; ; 

*  a ; 

*  rype  of  1  tun  1 

Define  structure  for  -lass  of  weapon  systems.  There  will  bi 
one  .  f  these  records  for  each  tore  of  wearer,  system. 


+ - ! 


name  -  STRING 


si  ah*: 


F.ETI  ~LE 


I  reload  time  <  time  t  I 

+ - o 

|  ammo  types  (  array  of  — >  MUNITION  CLASS  )  I 


!  ha'jic_load  (  array  of  int  )  I 

+ - + 
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char 
RETICLE 
time  f 


Ml Tank  MG 


name [ • 0 ] ;  /*  name  of  weapon  sys,  ex: 

♦sight;  ! *  sight  picture  used  for  this  weapon  ty 

reload_time;  /*  Minimum  time  between  firings  */ 

/*  Array  of  pointers  to  posible  munitions  for  this  weapon  sys 
MUN I T I ON_C  LAS  3  *ammo_types [MAX_RDTYPES_FER_WEAPON J ; 

/*  Array  holding  starting  quantities  for  avail  munitions  */ 

int  basic_load [MAX_RDTYPES_PER_WEAPON] ; 

}  WEAPONS; 


—  Define  structure  to  represent 

platform. 

weapon  system  carried  by 

a 

— 

1  wpn  class  - 

WEAPONS 

i 

1  range  reading 

1  safety  on 

(  refire  FLAG  ) 

i 

1  round  select  — 

>  MUN I T I ON_C LASS 

i 

1  last  fired 

(  t ime  ) 

i 

I  rounds  remaining!]  ( 

array  by  type  round  ) 

i 

*/ 

typedef  struct  weapon  record 

(  / *  instance  of  weapon 

*  ' 

/*  class  variable  */ 

WEAPONS  *wpn  class;  /*  ptr  to 

weapon  type  record  *, 
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/*  instance  variables 

float  range  reading;  / *  current  reading  in  rangefinder  * . 

Boolean  safety_on;  / *  flag  whether  weapon  safety  is  on  or  off  * 

/*  ptr  to  selected  round,  type  of  munition  currently  selected  */ 
MUNITION_CLASS  * round_select ; 

/*  time  system  was  last  fired,  0  if  never  fired.  */ 
time  f  last_fired; 

/*  array  of  rounds  of  each  type  of  munition  remaining  on  platform  */ 
int  rounds_remaining [MAX_RDTYPES_PER_WEAPON] ; 

}  WEAPON; 


Define  record  structure  for  timed  events 

+ - + 

I  delete  (  FLA'  t  I 

4. - + 

I  start_time  ;  tome  1  I 

+ - + 

I  last__update  (  time  )  ! 

4 - 1 

I  prccess_event  — >  fun;(  — tevent  !  I 

4 - 4 

I  ne::t_event  — >  event  I 

4 - 4 

I  variant  (  UNION  t  I 

4 - 4 


/*  P.ecord  for  event  variant  part  to  reset  something  on  a  weapon  after 
a  certain  amount  of  elapsed  time.  */ 
typedef  struct  weapcn_t imeout  ( 


time__f 

WEAFOH 


dur at  ion ; 
*wpnpt  r ; 
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)  WFN_TIMEOUT; 

typedef  struct  msg_type  ( 

time_f  duration; 

char  message [40]; 

}  MESSAGE_TYPE; 

typedef  struct  splash_record  ( 

Coord  ::,y,z;  *  Where  to  draw  round  splash 

)  S P LAS H_E VENT; 

typedef  struct  flaoh_reccrd  ! 

short  colornum; 

Vehicle  *hit vehicle; 

(  E LAS H_E VENT; 

typedef  struct  I  . *  Fecord  for  venicle  "bounce"  * 

Vehicle  *vehptr; 

float  fccunce_amp 1 it ude ; 

)  E0UNCE_E7ENT; 

typedef  union  type_events  ( 

ROUND_ I N_F  L I G  HT  round_aloft; 

WFN_TIMEOUT  wpntimeout; 

MESSAGE_TYPE  letter; 

SF  LAS  H_E7ENT  splash; 
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FLASH_£VENT  flash; 

BOUNCE_EVENT  bounce; 

/*  add  other  timed  event  types  here  */ 

)  EVENT_UNION;  /*  end  union  */ 

typedef  struct  event_record  { 

Boolean  delete;  Flag  indicating  expired  event 

time_f  start_t ime,  / *  time  event  was  initiated  *, 

last_update;  /*  time  when  event  was  last 

updated  * / 

int  (*  process_event ) (struct  event_reccrd  *); 

*  pointer  to  function  to  handle  this  event  * 
struct  event  record  *ne:-:t  event; 

EVENT  UNION  variant;  *  variant  part  of  record  * 

EVENTS;  *  end  struct  event  record  * 


Declare  global  variables  to  contain  the  values  fir  actual 
--  WEAPONS,  RETICLE,  and  MUNITION  CLASS  llasse 


extern 

WEAF 3  NS 

ml  tankmg  sabot, 

ml  tankmg  heat, 

bines  class, 

tow  ~lass; 

extern 

RETICLE 

mltank  gunner  reticle, 

binos  reticle, 

tow  reticle; 

extern 

MUNITION 

CLASS  ml  I05sabot, 

ml  lOfheat, 

tow  standard; 

extern 

WEAPON 

binos ; 
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INITIALIZE 


qetpath 

d9code_arguements 

deftnecursors 

initiris 

setcolor  initialize 

billboard 

light_model 

inil  months 

mal-epopups 

load_paths 


RUN 


event 


TERMINATE 


cleanup_on_@vrt 
exit  simulator 


Figure  A -3  MAIN  Module  Program  Flow 


control  input  loop 


setqueue 
setcontrols 
do_driving  menu 
set'jp_for_3rrving 
handle  controls 


handle  network  input 


update  guide  points  and  controls 


check  _tor_packets 


autopilot 


update  ,ehicle  model  tor  each  plattc'm 


updale_v oh  model 


update  vehicle  position  tor  each  platform 


update  veh  pos 


draw  ?D  view 


viewbounds 
display_nav 
display  firebov 
display_indbo» 
dra  wferram 
displaydata 
displa,  backed  data 


send  network  update  messages 


rigure  A-5  Display  l  oop  in  evenl  dri' ing 


Figure  A-6  Display  I.oop  in  event_flying 
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TABLE  A-2  SUPPORT  FUNCTIONS 


addf lash . c 

Adds  round  impact  flash  ®v®nt  to  th® 

event  list 

a  ddme  s  sage . c 

Adds  message  display  event  to  even*- 

list 

addsp lash . c 

Adis  round  splash  event  t ;  event  list 

addveh . c 

Adds  platform 

aps  .  c 

Main  routine 

arcsine . c 

Returns  arcsine  of  input  parameters 

aut  op i lot . c 

Computes  course  and  3peed  for 

plat  form ( s ) 

t  ill!'-.ar  d  .  c 

Displays  rctatim  tiilt  :ai  1  c  creen 

1  „  n e  .  c 

.3 vm.p utes  os ci  1  la*:,  i  .  r:  iu*-*  *■  '  ^na::: 

irregularities 

broadcast  rervioes.c 

Contains  low— level  network  routines 

f  :  r  r  i  .  a  d  o  a  s  t  rr.e  s  ?  a  a  e  s 

calc  pye  c  f f  sst . c 

..aiculates  world  r coition  t  viewer 

a  2  •  j  |  [.l  an®  . 

Fit.  “  ::r_u:i!  p  1  ar,»  ur.  .ie  i  terrain 

a  1  c  1 .  •_  k  p  a  r  air.et  era.  r. 

Calculates  viewer  ptsitm:  arid  view 

int-o f-aim 

•;  3  1  ”■  w  i  n  d  -  v;  p  .  ? 

C 3 1  sulat  es  windows  n:--?  and.  ?*■  r  °s 

i r.  an  a r  r a y 

c  <=*  r*.  *■  °  i  c  ■  .1  r  ?  ?  r  .  c 

Positions  cursor  in  she  renter  ; t  a 

w  i  n  d  ;  w 

-op*-  c.  r  pt-rirvj  map  .  •? 

Fri.nts  a  centered  strini  in  t  he  MAT 

wind . w 

-■  o »•; ♦-  o  p  gf  ^  *  p  ^  rr,p n  u  .  * ' 

Prints  a  center®*  i  .<?*•  run  in  *  h®  MFN" 

window 

check  for  packet s.c 

Handles  the  reception  and  pi  •cess i uj 

of  network  messages 

check  round  in  flight. c 

Updates  round  position,  handles 

round  impact  with  platform  or  ground 

clearwir.dow.c 

Clears  a  window  to  input  color 

c o Ira  n  o rma 1 s . c 

Calculates  normals  for  Cobra 

helicopter 

collision  detection. c 

Detects  collision  between  any  two 

p 1 at  f . rms 

- • mr  ut «  si  p® . ■  • 

Computes  t  h®  slope  of  a  line 

compute  start  stop.c 

Computes  information  for  drawee:  ram 

1  14 
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compute  sun  location. c 

Computes  sun  (light  source)  location 

based  on  month  and  hour 

compute  x  bounds. c 

Computes  x  drawing  limit  for 

drawterrain 

compute  o  bounds. c 

Computes  z  drawing  limit  for 

drawterrain 

convert  to  dec  hr.c 

Converts  to  decimal  hour 

convert  to  hr  min.c 

Converts  to  hours  and  minutes 

decode  arguments.; 

Handle  command  line  arguments  when 

aps  in  started 

cis  £  i.  n  0  ^  u  t  s r  s  .  c 

S  e t s  ■  j  p  cursor  shapes 

.  j  g  |  e  f  e  '.'0ii  .  C 

Deletes  a  platform  and  fr  °es  spa 

display  1  i  ti  rr,3 u  .  c 

[  i  splays  2  5-  KM  if-  mat 

display  dat a . c 

f ist lays  current  system  parameters 

~  *  j  s  0  r 

d  i  s p  1  a y_e  1 3 1:  s e  ;i_r  :r.e  .  : 

•  r."c?rl  j  £  1 ad  r.  r  tint  y  <=.-  •  ■ .  J c  2:/ 

Hl-13  £  .  1  ma  1 1  e  ,i  string 

dist  lav  f  i  r 0 ir  t x  .  i? 

!  x  3 r  1 3 v s  itic  U3°  1 0  ti ^  n ti  £  ”  t  r  ^  *■  £  -  r m. 

with  weapon  system  active 

d  i  s  i  1  a  y  i  r  *  n  .  c 

Displays  all  platform  icons 

drop  lay_indbo;: .  c 

lisp  lays  mouse  legend  for  pi  a",  form 

without  weapon  system  active 

display  i  r.  db  c x  f  o gm .  c 

Displays  mouse  legend  for  FvGM 

p 1  at  f .  rm 

display  ir.tr-:  o  :  r  e  e  r. .  c 

Dirylay?  t  r: 0 r am  in?*"  r  y  r 7 1 : •  n ? 

•display  leuen.i  f.i  1  u  map  .  r 

lisp  lays  color  gradation  for 

elevation  on  2 5 KM  map 

display  legend  for  navbcx.c 

Display's  color  gradations  tor  slope- 

colored  2D  10  KM  map-  used  for  path 

planning 

display  map . c 

Draws  1°KM  2D  map 

display  n  a  v . c 

Draws  blue  course  arrow  and  field-. f- 

view  limits 

display  slider . ; 

Displays  tracking  controls  for  FOGM 

p I  a  t  f  c  rm 

dist  lay  track1?  d  rr\0  s  s  a  a  e  .  y 

Displays  tracking  messa:i°  on  the 

3:r°?n 
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do  capture. c  Handles  storing  platforms  into  data 

file 

do_change_speed . c  Allows  user  to  set  the  speed  of  all 

plat  forms 

do  char.c  Displays  a  character  in  file  name 

window 

do  driving  menu.c  Displays  driving  menu  and  handles 

select  ion 

do  f ly ing_menu . c  Displays  flying  menu  and  handles 

3?l$ct ion 

do  intros. c  Handles  selection  to  display  user 

instruction  window 

do  main.c  Builds  and  displays  mam  menu  and 

handles  selection 

do  mam  reset,  c  Clears  all  windows  and  displays  CD 

t  e  i  r  a ir.  map 

de_path.eps.  c  Builds  and  displays  path  operations 

rp.e  nu  i  'nsnTil^s 

do_quitt ing . c  Handles  program  exit  selection  from 

any  menu 

do  resize . c  Handles  resize  seiecti-n  from  any 

menu 

do  select  area.c  Handles  menu  selection  of  a  1  OKI-1 

operational  area  on  the  ?or'l-i  map- 

do  the  add . c  Handles  menu  selection  of  addins  a 

plat  form 

do  *■ dv-  1°  fa'il  *'s.c  Handles  menu  selection  of  adlin.u  a 

default  set  of  platforms 

do  the  delete. c  Handles  menu  selection  of  deleting 

one  or  all  platforms 

do  the  select. c  Handles  the  selection  of  a  platform 

dr aw_box_around  current  area.c  Draws  red  box  around  current  1  OKI-1 

area  on  large  map 

draw_cotra.c  Draws  the  main  body  of  the  attack 

;»el  icopter 

draw  cruidept  .  c  Draws  a  guide  point  as  a  marker  on 

the  terrain 
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draw  in  cobra. c 


draw  main  rotor. c 


dr aw_pro  ject i le . c 
draw  reticle. c 
draw_tail_pipe . c 
draw  tail  rotor. c 


d  r  a  w  f  1  a  s  h  .  c 


drawer  idb  .  c 
dr  awaua . u 


dr  v.-;r  •  -;S .  ' 


•Jr a  w  j  e  e r.  .  c 
drawmi  ssile.  ■: 
:!  raw  ■  per.  ;e“p  . 
drawr : 1 le  r  .  j 
draw; p las h. .  ; 


drawt ank  .  c 


Jr awtarrain, 


d  r  a  w  t  r  r  e 


drawt  rack . c 
■jrawtruck  .  c 
drawturit . c 
dr awwreck . c 
error  handle r . 


event . c 

eventdr ivmg . c 
event  flying. c 


Draws  the  cockpit  framework  when 
looking  from  inside  the  attack 
helicopter 

Draws  attack  helicopter  main  rotor 
blade 

Draws  round  in  flight 

Draws  weapon  sight  picture 

Draws  attack  helicopter  IP.  suppressor 

Draws  attack  helicopter  tail  rot-r 

Draws  flame  from  tail  f  FT.  GM 

Draws  flash  when  round  impact  ?  a 

p  1  at  form 

Draws  a  bo::  in  the  map  wind  w 
Draws  the  tank  barrel  and  '  ire 


“a  -h  t  e 


e 1 1  s  i  mu  1  a  t 


evacuator 
flaws  the  :  r. 

plat  form 
Draws  the  deep 
Draws  the  FOGM 
Draws  t  he  ter. 


Draws  the  tank  rollers 
Z raws  the  ground  splash  when  a 
projectile  impacts  the  around 
Draws  the  body  ~f  the  tank 
Mam  terrain  and  platform  dr  aw  in  .> 
rout i ne 


Draws  a  tank  track 

Draws  the  truck  body 

Draws  the  tank  turret 

Draws  a  burning  wreck 

Centralized  error  handler,  just 

prints  error  message  and  returns 

Main  drawing  cycle  dispatch  routine 

Ground  platform  drawing  cycle 

DOOM  drawing  '~ycle 

Cleans  up  on  e.oit 
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explosion . c 

f ire_blast . c 
fire_weapon . c 
flame norma  Is  .  c 
gen_wildman_defaults . c 
get_curr_fps . c 

get_mouse_:zy . c 
get_name . c 

gnd_level . c 

gnd_level_”TM. c 

guidance  .  c 

gunnorma Is . c 
handle_crash . c 
handle_e vent s . c 
ha.ndle_tracking .  c 
handleccntrcis  .  c 

handlecont  rols_fogm . c 

handle  c  c  nt  re  1 s_p  artial . r 

highlitegr id . c 

init  font s  .  c 

init_months . c 
init_network  .  c 

init_weapons . c 

initialize  terrain  mat . c 


Flashes  screen  when  current  platfcrm 
is  destroyed 

Flashes  screen  when  weapon  fires 
Handles  weapon  firing 
Computes  normals  for  the  FOGM  flame 
Generates  a  default  set  of  platform? 
Calculates  current  drawing  rate  in 
frames  per  second 

Gets  current  location  of  mouse  cursor 


Opens  window  for  user 

t  o  enter  file 

name 

Compute?  around  level 

of  input  world 

c _or  din at es 

Computes  ground  level 

of  input  VTM 

c : c rd i nat «*s 

lentains  routines  to  h 

anile 

transition  between  am 

i  a n  r  e  states 

omp ut es  normals  for  t 

a  n  k  barrel 

Handles  collision  of  two  platforms 
E'-en.t  handler  package 

Handles  FOGM  tracking  gr.un.i  plat- firm 
Handles  meuse  and  dial  inputs  when 
driving  a  ground  platform 
Handles  dial  inputs  when  flying  the 
F  GM 

Handles  mouse  inputs  when  flying  the 
FOGM 

Highlights  the  1X1  KM  grids  that 
contain  any  platforms  for  zooming 
Initializes  fonts  and  scales  them  to 
window  size 

Initialize  month  and  lighting 

Set  up  network  sockets  and  stream 

server  connection  queue 

Initializes  any  weapon  systems  on 

beard  a  platform 

Defines  materials  for  terrain 

polygons  based  on  current  o:  111  map 
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initiris  .  c 
initveh . c 
jeepnormals . c 
letter  .  c 

light_model_initialize . c 
lightdef s  .  c 
limit_cursor  pick.c 

1  iir.it  va  1  ue  .  c 

1  -  a  dunit  .  c 
makepopups . c 
maket  ank . c 
n.aketer  rain .  c 

m 3. k 0 is  ^k  .  : 
mapover lay . c 

math_utiiity . c 
m  1 7-  s  i  1  e  r.  .  rma  1  s  .  r 

mou9estr°9nt outm . z 

mouses  or  eer.t 

msuset  e  rramtcutm.c 

mouseutmt oscreen  .  c 

mouseutmtoterram  .  c 

mousewer ldt oscr een . e 

rpam  spr”ic®s  .  c* 

network  .  s 


Initializes  graphics  system 
Adds  platforms  from  a  file 
Computes  normals  for  a  jeep 
Draws  a  letter  on  the  billboard 
Initializes  lighting  model  and 
lighting  viewer  definition 
Defines  materials,  lights,  and 
lighting  model 

Limits  cursor  for  targeting  attempt 
by  FOGM 

Limits  value  between  upper  and  lower 
bound 

Loads  a  uni*:  matri;:  ont  .  t  he  sta  rk 
Builds  static  menus 
Builds  polygon  arrays  for  tank 
Fills  the  terrain  elevation  and 
terrain  polygon  normal  arrays 
Makes  tank  track  polygons 
Draws  the  platform  icons  cn  the  2D 
i  KM.  map 

Package  of  math  utility  functions 
Calculates  n-rmals  for  r  F'"'~M 
mi s  s i le 

Converts  screen  ipinell  coordinates 
to  UTM  coordinates 

Convert  s  fr-'ro  screen  s  o  :  rdma*"  es  to 
world  graphics  coordinates 
Converts  from  10 KM  coordinates  tc 
UTM  coordinates 

Converts  from  UTM  coordinates  to 
point  on  the  screen 
Converts  from  UTM  coordinates  to 
10KM  coordinates 

Converts  from  2D  world  coordinates 
to  screen  coordinates 
Fa’~kage  contamina  routines  t  ^ 
manaoie  stream  connections 
Builds  messages  and  sends  them 
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network  10. c 

Package  of  message  level  network 

communication  routines 

normalorient .c 

Computes  normal  and  reorganizes 

vertices  of  polygons 

npoly  orient . c 

Orients  polygon  vertices  for 

backface  method  of  hidden  surface 

remova 1 

obstacles  .  c 

Stub  module  for  obstacles  package 

open  jeepnorma Is . c 

Computes  normals  for  open  jeep 

path . c 

Package  of  routines  to  manage  paths 

placewindow  sizes,  c 

Sets  aspect  and  size  for  billboard 

window 

placewindows . c 

Calculates  the  p:siti:n  of  all 

windows  and  opens  them 

pc  p-wi ndc  w  .  c 

Fops  a  window  ini:  full  view 

positicr.windcws  .  c 

P  :s:ti:ns  wind:  v: 3  un  i ~ r  w  1  r:  .1 .  w 

manage r 

range  f inde r . 7 

Simulate?  a  laser  rang® finder  and 

calculates  the  range  to  nearest 

platform  in  weap-n  sigh*-  sshairs 

read  data .  o 

Reads  elevation  and  vegetati.n  data 

from  file 

reset  tiltf.c 

Resets  FOGM  tilt  angle  after 

releasing  tracking  mode 

ret i cles  .  c 

Variable  definitions  for  sight 

reticle  arrays 

ring  the  bell . c 

Rings  the  terminal  bell 

roller normals . c 

Computes  normals  for  tank  rollers 

select  an  area.c 

Handles  selection  of  an  area  35KM 

map 

select  grid  square. c 

Handies  selection  of  1  X  1  KM  grid 

square 

select_sight . c 

Displays  viewing  mode  menu  and 

handles  selection 

set  driven  view.c 

Sets  viewing  parameters  for 

perspective  and  eye  geometry 

set  popup  color. c 

Sets  the  color  of  the  popup  menus 

set  queue . c 

Queues  up  dials  and  mous® 
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set  unqueue . c 

Unqueues  dials  and  mouse 

setcolor . c 

Sets  current  RGB  color  based  on 

values  in  RGB  color  array 

setcolor  initialize. c 

Initializes  RGB  color  array 

setcontrols . c 

Sets  up  controls  for  driving 

setcontrcls  fogm.c 

1 

Sets  controls  for  flying  the  FOGM 

missile 

setcurscrcolor . c 

Sets  the  ''orient  color  of  the  cursor 

setup  for  driving. c 

Sets  up  for  driving  usinj  mouse 

joystick 

setup  navwin.c 

Draws  small  2D  1C  KM  map  in 

navigation  window 

setwinlow. r 

Fut  s  focus  into  a  wind  w 

setwor ldcoord . c 

Saves  world  coordinates  of  window 

Q  imf.  ime  .  c 

Package  containing  routines  t; 

manage  simulation  time 

sin::s  .  r 

Returns  interpolated  table  lookup 

values  for  sine  and  cosine  functions 

switch  veh . c 

Returns  pointer  to  platform  selected 

with  mouse 

tank norma Is . o 

computes  normals  for  a  tank 

t  e  r  r  a inno rma Is.' 

Computes  normals  for  the  terrain  and 

stores  them  in  an  array 

t i renormals . o 

Computes  normals  for  a  tire 

tot  num  ground  ••“h." 

returns  total  number  --f  ground 

p 1  at  f o rms 

tot  num  veh.  c 

Returns  total  number  of  plat  ft rms 

t  r  acking_check . c 

Performs  check  of  FOGM  tracking 

system 

tracknormals . c 

Computes  normals  for  tank  tracks 

t  r uckncrmals . c 

Computes  normals  for  truck 

tur it no rma Is . c 

Computes  normals  for  tank  turret 

update  look  pcs.c 

Calculates  position  that  viewer  is 

looking  at  for  ground  platform 

update  lock  pcs  fogm.c 

Calculates  position  that  viewer  is 

looking  at  for  FOGM  missile 

update_veh_pos .  c 

Moves  platform  to  new  position 

ve  cdctp .  c 

Computes  vector  dot  product 
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vecmag . c 
vehmcdel . 


TABLE  A-2  SUPPORT  FUNCTIONS  -  CONTINUED 


Computes  magnitude  of  a  vector 
Package  containing  vehicle  motion 
modeling  routines 
Computes  viewing  limits  for 
drawter rain 


viewbounds . c 


APPENDIX  B  PATH  PLANNER  CODE 


;;;  Mode  LISP;  Package  USER.  Syntax  Common-lisp  -*- 
.Title:  clock  functions 
(Author.  Shannon 
.Date  12  Apr  1989 

.Discnption  This  program  provides  for  the  timming  of  clocks  used  in  the  Path  Planner  Control  Program 

(defflavor  myclock  ((start-iris-ome  0) 

(start-sym-time  0) 

(last-iris-Ome  0) 

(last  sym-time  0) 

(delta-time  0) 

) 

0 

imtable-instance-variaples; 


(defmethod  (  set-start-time  myclock)  (iris-time) 
(let*  () 

(serf  last-irr-ti me  iris-time) 

(sett  start-iris-time  iris -ti me) 

(setf  start-sym-time  (zl  time)) 

(serf  last-sym  -time  start-sym-time) 

(setf  delta-time  0) 


(defmethod  (  reset- last-time  myclock)  (ins-time) 

(let*  ((delta  1  0  0)  (oelta2)) 

(progn 

(sett  iast-sym-time  (zl  time)) 

(setf  last-ins-time  iris-time) 

(setf  della  1  (-  iris-time  start-, ns-timei) 

(setf  delta2  (  Iast-sym-time  start-sym-time)) 

) 

) 

) 

(defmethod  (  get-nme  myclock)  () 

(+  delta  time  (/  (♦  0  0  (time-difference  (zt  time)  Iast-sym-time))  PLj  last-iris-time) 

) 

(defmethod  (  get-all-times  myclock)  () 

(pnnc  start-ms-time) 

(pnnc  start-sym-time) 

(pnnc  last  ms  time) 


(princ  last-sym-tme) 
(pnnc  delta-time) 

) 
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Mode  LISP,  Syntax  Common-lisp,  Package  USER-"- 
, Title  chaosflavor  lisp 
.Author  Kwak 
.Modified  by  Shannon 
.Date  19  Apr  1989 

;Discnpbon  This  code  performs  the  communications  between  Symbolics  computers  using  a  character  stream 


(load  "comm-functions") 

(def flavor  mychaos  ((host  name  syml) 

(contact-name  "user-chaos") 
(contact  ml) 

(userstream  nil) 


0 

in  itabie- instance -variables) 


(defmethod  (  set-host-name  mychaos) 

(name -of  host) 

(seif  host-name  name-ot-host)) 

(defmethod  t  set-contact-name  mychaos)  (name) 

(self  contact-name  name)) 

(defmethod  (  set-contact  mychaos)  (con) 

(setf  contact  con)) 

(defmethod  (  set-stream  mychaos)  (str) 

(setf  userstream  str)) 

(defmethod  (  start-user  mychaos)  (hostname  contactname) 

(progn 

(send  self  set-host-name  hostname) 

(send  self  set-contact-name  contactname) 

(send  self  set-contact  (chaos  connect  hostname  contactname  13  72000); 
(send  self  set-stream  (chaos  make-stream  contact  direction  bidirectional)) 
(terpn) 

(pnnc  "host  name  *  )  (princ  host  name) 

(terpn) 

(pnnc  "contact  name  ")  (pnnc  contact-name) 

(terpn) 

"A  conversation  using  chaos  has  been  established")) 


(defmethod  (  start  server  mychaos)  (contactname) 
(progn 


(send  self  set-contact-name  contactname) 

(send  self  set-contact  (chaos  listen  contactname)) 

(chaos  accept  contact) 

(send  self  set-stream  (chaos  make-stream  contact  direction  Didirectionalj) 

(terpn) 

(pnnc  'host  name  ‘  )  (pnnc  host-name) 

(terpn) 

(pnnc  'contact  name  ')  (pnnc  contact-name) 

(terpn) 

"A  conversation  using  chaos  has  been  established')) 

(defmethod  (  put  mychaos) 

(object) 

(send  userstream  line-out  object) 

(send  userstream  force-output) 

) 

(defun  read-stnng  sym  (stream  num-chars) 

(let  ((out-stnng  ")) 

(dotimes  (i  num-chars) 

(serf  out-stnng  istrmg-append  out-stnng  /eac-cnar-no-nang  stream);) 

) 

out-stnng 

) 

) 

(defmethod  (  check-syrn  mychaos!  tsize-io) 

(let*  ((typebuher ) 

> 

(progn 

(setq  typebuffer 

(reao-string-sym  userstream  size- 10) i 

I 


(defmethod  (  put  ready  mychaos) 

(object) 

.From  path-planner  to  art 
(let*  ((buffer  '""*)) 

( serf  buffer  (stnng-append  (stnng  append  buffer  object) '"")) 
(progn 

(send  userstream  line-out  buffer) 

(send  userstream  force-output) 
t 

) 
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) 

) 

(defmethod  (  put-waypomt  mychaos) 

(object) 

;(rom  path-planner  to  art 
(let*  ((buffer  *@@@@*)) 

(serf  buffer  (stnng-append 

(stnng-appiend  buffer  (convert-number-to  stnng  object)) 
’ @©@“ )) 

(progn 

(send  userstream  line-out  buffer) 

(send  userstream  force-output) 
t 

»)) 

(defmethcd  (  load-map  mychaos) 

(utm-e  ut.Ti-n  veh-id) 

From  art  to  path  planner 
(let*  ((buffer 

tsed  buffer  (string -append 
(stnng-append  buffer 

(convert  number-to-sinn 


) 

J 

) 

(progn 

(send  userstream  ime  cut  buffer) 

I  send  userstream  tc-ce  Output. 

t 

))) 

(defmethod  (  put-path  mychaos,' 

(org -utm-e  org-utm-n  start  utr,i-e  start  utm-n  gca.  utm-e  goal-utm-n  veh-  dj 
,trom  an  to  path -planner 
(let*  ((buffer  *(a)@@@*) 

(stnng-or^-e  (convert-number  to  stnng  org  utm-e)) 

(string -org-n  (convert-number  to  stnng  org  utm-n)) 

(string  start-i  (convert-number-to-stnng  starl-utm-e)) 

(string  start  n  (convert  number  to-stnng  start  utm-n)) 

(string  goal-e  (convert  number -to- string  goal  utm-e)) 

( stnng -goal-and  id  (convert  number-to  sfnng 


g  .(-  !*  utm-e  lOOCXXOOOOOOOO) 
>,  utm-n  f  -ju  uu-  Du  uC  ju  ) 

veh-id 

) 


Ml 


(+  ('  goal-utm-n  10000000000) 
veh-id 
) 

) 

) 

) 

(serf  buffer  (stnng-append 
(slnng-append 
(stnng-append 
(stnng-append 
(stnng-appeno 
(stnng-append 
(stnng-append  buffer 

stnng-org-e 

) 

string -org-n 
) 

stnng-start-e 

) 

stnr.g-start-n 

) 

stnng-goal-e 

) 

stnng-goal-and-id 

) 

”@©@- 

) 

) 

(progn 

(send  userstream  Ime-ou!  buffer) 

(send  userstream  force-output) 
t 

) 

) 

) 

(defmethod  (  stop  mychaos) 

0 

(send  userstream  close  abort;) 


Mode  LISP,  Syntax:  Common-lisp,  Package  USER-’- 
.Title  insflavor3  lisp 
.Author  Kwak 

.Modification  Author  Shannon 
.Modification  Date  20  May  1989 

;Discnpfion  This  code  provides  communications  functions  to  the  symbolics  workstation,  whereby  it  can 
communicate  to  the  Ins 


(defmacro  loopfor  (var  mit  test  expl  &optional  exp2  exp3  exp4  exp5) 

'(prog  () 

(setq  ,var  ,mit) 
tag 
.expl 
.exp2 
,exp3 
,exp4 
,e*p5 

(setq  .var  (1  -  .var)) 

(if  (=  .var  test)  (return  !)  (go  tag),)) 


(load  ’comm-functions’) 

(defvar ’ms-portr  1061) 
(defvar  ’iris-por:2’  1061) 
(defvar  ’local-talk-port’  1500) 
pon 

(defvar  'local-listen  port’  1501) 
receive  port 


,  this  is  the  send  port 
.  this  is  the  receive  port 
.  th.s  is  me  loca1  send 

this  is  the  local 


(defflavor  conversaOon-with-iris  ((talking-port  number  ’iris-portl*) 
(iistenmg-port-number  Tris-pcrt2') 
(local-talk-port-number  ’local-talk-porf) 
(locai-listen-port-number 

’local-listen-port’) 

(talking-stream) 

(listening-stream) 

(destination-host-ob)ect) 

) 

0 

initable-mstance-vanables) 


(defmethod  ( init-destmabon-host  conversation-with-ins) 
(name-of-host) 

(setf  destination-host-object  (net  parse-host  name-of-host))) 
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(defmethod  (  start-ins  conversation-wittviris)  () 

(serf  talking-stream 

(tcp:open-tcp-stream  destination-host-ob|ect 
talking-port-number 
locaJ-talk-port-number)) 

(setf  listening-stream 

(tcp.open-tcp-stream  destination-host-object 
listening- port-number 
ioc«ii-iiaien-porl-..ui,iUjry) 

‘A  conversation  with  the  ins  machine  has  been  established") 

(defun  read-stnng  (stream  num-chars) 

(let  ((out-stnng  ")) 

(dotimes  (i  num-chars) 

(setf  out-string  (string-append  out-string  (read-char-no-hang  stream)))) 
out-string)) 

(defmethod  (  check-ins  conversation-with-iris)  (size-io) 

(let*  ((typebuffer) 

) 

(progn 

(setf  typebuffer 

(read-stnng  listening-stream  size-io) 

) 

) 

) 

) 

(defvar  'step-var'  0) 

(defun  my-wnte-stnng(stnng  stream) 

(let*  ((num-chars  (length  stnng))) 

(dotimes  (i  num-chars) 

(wnte-char  (aref  string  i)  stream) 

) 

) 

) 

(defmethod  (  put-waypoint  conversaton  with-ins) 

(veh-id  utm-e  utm-n) 


(let*  ((buffer  (stnng-appeno 


(stnng-append 
(convert-number-to-string  veh-id) 
(stnng-append 

(stnng-append 

(convert-number-to-stnng  utm-e) 
(string-append 

(stnng-append 

(convert-number-to-string  utm-n) 


(buffer-length  (length  buffer)) 


(lengthbuffer  (convert-number-to-str;ng  buffer-ieng 


(progn 

( my- wnte- string  bu^er  m.lkjng-stream) 
(send  talking-stream  force-output) 


(defmethod  (  stop-ms  conversation-with-ins) 

0 

(progn  (send  talking  stream  ciGse) 

(send  listening-stream  close))) 


;;;  Mode:  LISP,  Syntax:  Common-lisp,  Package.  USER 
;title  comm  functions 
.author  Kwak 

.discnption  This  program  provides  functions  to  the  communications  progarams  that  convert  to  and  from  strings 
and  numbers. 


(defun  convert-number-to-string  (n) 

(pnnc-to-string  n)) 

(defun  convert-string-to-integer  (str  Soptional  (radix  10)) 

(do  ((j  0  (+  j  1)) 

(n  0  (+  ('  n  radix)  (digit-cnar-p  (char  str  j)  radix)))) 

((=  j  (length  str))  n))) 

(defun  find-period-index  (str) 

(catch  exit 

(botimes  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  C)) 

(throw  exit  x))))) 

(defun  get-leftside-of-real  (str  &optional  (radix  10)) 

(do  (0  0  (1+  j)) 

(n  0  (*  (*  n  radix)  (digit-char-p  (char  str  j)  radix)))) 

((or  (null  (digit-char-p  (char  str  j)  radix))  (=  |  (length  str)))  n))) 

(defun  get-nghtside-of-real  (str  ^optional  (radix  10)) 

(do  ((index  (1+  (find-period-index  str))  (1+  index)) 

(factor  0  10  (*  factor  0  10)) 

(n  0  0  (+  n  (’  factor  (digit-char-p  (char  str  index)  radix))))) 

((=  index  (length  str))  n  ))) 

(defun  convert-strmg-to-real  (str  Soptional  (radix  10)) 

(♦  (float  (get-leftsde  of-real  str  radix))  iget-rightside-of-real  str  radix))) 
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Mode:  LISP,  Package  USER;  Syntax  Common-lisp 
Tide  define-packege-interface 
.Author  Shannon 
:Date  24  May  1989 

.Discnption  Defines  the  interface  between  programs  running  in  different  Symbolics  packages 

#L(defpackage  d-user 
(export 

conversation-with-ins 

mychaos 

mydock 

convert-number-to-stnng 

convert-stnng-to-real 

convert-stnng-to-mteger 

string-append 

princ-to-string)) 
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%%%  Mode  ART.  Syntax:  Common-lisp.  Base.  10.;  Package  ART-USER 
.Title:  Path  Planner  Control  Program 
lauthor:  Shannon 
;Date:  1 1  June  1989 

.Oiscnption  This  program  provides  the  overall  control  logic  for  finding  a  path  and  the  sending  that  path  to 
;  the  vehicle  simulation. 

#L(load  "irisflavorS") 

#L(load  "chaosflavor") 

#L(load  "def-interface") 

#L(load  ■dockflavor") 

#L(defvar  talk-s) 

#L(defvar  taJk-i) 

#L(setf  talk-i  (scl. make-instance  'user  conversaBon-with-ins)) 

#L(setf  talk  s  (scl  make-instance  'user  mychaos)) 

(defschema  counter 
( seq  0) 

) 

(defschema  obsticle 

(instance-of  counter) 

(nw-utm-e  000) 

(nw-utm-n  000) 

(sw-utm-e  000) 

(sw-utm-n  000) 

(se-utm-e  000) 

(se-utm-n  000) 

(ne-utm-e  000) 

(ne-utm-n  000) 

(seq  000) 

(seq-ord  last) 

) 


(defschema  ob|-type 
(type  unk) 

) 

(defschema  location 
(utm-e  000) 
(utm-n  000) 

) 

(defschema  id 

(veh-id  000) 

) 
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(defschema  map-state 

(ready  not-yet) 

) 


(defschema  clock 

(dock-id  new) 

(time  000) 

) 

(defschema  control-conditions 
(new-goal  no) 
(quit-all  no) 
(broke-down  no) 
(pause  no) 
(whole-path  no) 
(new-time  no) 
(new-waypomt  no) 
(old-time  0) 

) 


(defschema  mitial-map-points 
(org-utm-e  000) 
(org-utm-n  000) 
(start-utm-e  000) 
(start-utm-n  000) 
(goal-utm-e  000) 
(goal-utm-n  000) 

) 


(defschema  control 

(instance-of  clock) 

(mstance-of  ob|-type) 
(instance-of  id) 

(instance-of  counter) 

(instance  of  control-conditions' 

) 


(defschema  map 

(instance-of  obj-type) 
(instance-of  location) 
(mstance-of  id) 
(instance-of  map-state) 
) 

(defschema  init 

(mstance-of  obj-type) 
(mstance-of  id) 
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(instance-of  inifial-map-pomts) 

) 

(defschema  veh 

(cse  0) 

(vel  0) 

(guide  0) 

) 

(defschem a  veh-change 
(delta-time  0) 

(new-position  no) 

) 


(defschema  msg-state 
(current  no) 

) 

(defschema  veh-state 

(instance-of  ob|-type) 
(instance-of  veh) 
(instance-of  id) 
(instance-of  location) 
(instance-of  ven-change) 

) 

(defschema  veh-msg 

(mstance-of  dock) 
(instance-of  obj-type) 
(instance-of  veh) 
(instance-of  id) 
(instance-of  locaDon) 
(instance-of  msg-state) 

) 

(defschema  machine-type 
(one  one) 

(two  two) 

(three  three) 

(four  four) 

(five  five) 

) 

(defschema  sym 

(mstance-of  machine-type) 
(one  syml) 

(two  sym2) 
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(defschema  ins 

(instance-of  machine-type) 

(one  gravy  1) 

(two  gravy2) 

(three  gravy3) 

(four  gravy4) 

(five  gravyS) 

) 

(defrelation  msg-sym  (’type)) 

(defrelation  msg-ins  (’type)) 

(defrelation  start-ms-comm  (’t-or-f)) 

(defrelation  start-sym-ccmm  (’t-or-f)) 

(defrelation  menu  (’one-or-two;) 

(defrelation  sym-on  v?yes)) 

(defrelation  check-comm  (’ms-and-sym)) 

(defrelation  clock-update  (’yes)) 

(defrelation  sym-link  (’code)) 

(defrelation  iris-lmk  (’code)) 

(deffacts  initialization 
(menu  one) 

) 


(defrule  menul 

(declare  (salience  -1000)) 

(schema  sym 
(one  ’si) 

(two  ’s2) 

(three  ’s3) 

) 

’a  <-  (menu  one) 

=  > 

(pnntout  1 1  'Where  is  the  path  planner  located’-) 

(pnntout  1 1  "Your  choices  are  the  following,  chose  one  by  it's  letter  ' 


7 


i 


fa  "’si 
t -b  ‘  7s2 
t  "c  '  7 S3 

t  "NOTE— Please  ensure  that  the  path  planning  software  is  running 
t) 

(bind  ?b  (read)) 

(if  (or  (eq  ?b  a) 

(eq  ?B  A)) 
then 

(assert  (sym-link  7s1) 

(menu  two) 

(start-sym-comm  yes) 

) 

else 

(if  (or  (eq  ?b  b) 

(eq  7b  B)) 
then 

(assert  (sym-link  ?s2) 

(menu  two) 

(start-sym-comm  yes) 

) 

else 

(if  (or  (eq  7b  c) 

(eq  7b  C)) 
then 

(assert  (sym-link  7s3) 

(menu  two) 

(start-sym-comm  yes) 

) 

eise 

(retract  7a) 

(assert  (menu  one)) 


(retract  7a) 

) 

(cfefrute  menu2 

(declare  (salienoe  -1000)) 
(schema  iris 
(one  7il) 

(two  7i2) 

(three  7i3) 

(four  7i4) 

(five  ?i5) 

) 
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7a  <-  (menu  two) 


(pnntout  1 1  'Where  is  the  vehicle  simulator  located7') 

(printout  1 1  'Your  choices  are  the  following,  chose  one  by  it  s  letter 
t'a  '  7i1 
t  'b  '  7i2 
t  'c  '  7i3 
t 'd '  7i4 
t  'e  '  7i5 

t  'NOTE— Please  ensure  that  the  simulator  is  running' 
t) 

(bind  7b  (read)) 

(if  (or  (eq  7b  a) 

(eq  7b  A)) 
then 

(assert  (ins-link  7i1 )) 

(assert  (start-iris-comm  yesl) 
else 

(if  (or  (eq  7b  b) 

(eq  7b  B)> 
then 

(assert  (iris-link  7i2)) 

(assert  (start-iris-comm  yes)) 
else 

(if  (or  (eq  7b  c) 

(eq  7b  C)) 
then 

(assert  (ms-link  7i3)) 

(assert  (start-ins-comm  yes ;) 
else 

(if  (or  (eq  7b  d) 

(eq  7b  0)) 
then 

(assert ;  r:s-i  nk  7,4(; 

(assert  (start-ins-comm  yes;) 

else 

(if  (or  (eq  7b  e) 

(eq  7b  E)) 
then 

(assert  (ins-link  7i5)) 

(assert  (start-ins-comm  yes)) 
else 

(retract  7a) 

(assert  (menu  two)) 

) 
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) 

(retract  ’’a) 

) 

(defrule  start-ms-comm-links 
(declare  (salience  -1000)) 

(ins-link  ?ms-machme) 

7a  <-  (start-iris-comm  yes) 

=> 

#L(scl  send  talk-i  init-destmation-host  7 ms-machme ) 
#L(scl:send  talk-i  start-ms) 

(retract  ?a) 

(assert  (check-comm  ms) 

) 

) 

(defrule  start-sym-comm-lmks 
(declare  (salience  -10C0)) 

(sym-lmk  7sym-machme) 

7a  <-  (start-sym-comm  yes) 

=  > 

#L(scl  send  talk-s  start-user  7sym-machine  'path') 
(retract  7a) 

(assert  (sym-on  yesj 

) 

> 

(defrule  check-comm  iinks-  r  s 
(declare  (salience  500j) 

7a  <-  (check-comm  ms) 

=> 

(bind  7b  #L(sd  intern  (scl  send  talk-i  check-ins  1))) 
(if  (eq  7b  ML)  then 
(retract  "’at 
(assert 

(check-comm  ms) 

(checkcomm  sym) 

(dock-update  yes) 

) 

else 

(retract  7a) 

(assert  (msg-ms  7b)) 

) 


(defrule  check-comm-lmks-sym 
(declare  (salience  500)) 
ischema  7any 

(or  (ready  sent) 

(ready  ready) 

) 

) 

’a  <-  (check-comm  sym) 

=> 

(bind  7b  #L(sd  intern  (scl  send  talk  s  check-sym  1))) 
(if  teq  7b  NIL)  then 
(retract  ?a) 

(assert  (check-comm  ins)) 
else 

(retract  7a) 

(assert  (msg-sym  7b)) 


(defrule  read- update- in 

(declare  (sal.ence  1000)) 

7m$g  <-  imsg-iris  7aj 
(test  teq  7a  '>)) 

=> 

(bind  7b  #L(sd  intern  (scl  send  talk-i  check-iris  3,j) 

('f  (eq  7b  >>>)  then 

(t  nd  7veh-id  #L(scl  send  talk-i  check-iris  IC.ij 
(bind  7utm-e  #Lisd  send  talk-i  check-ins  1 0)) 

(bind  7utm-n  #L(sd  send  talK-i  check-iris  10)) 

(bind  7cse  #L\Sd  send  talk-i  check-ins  10)) 

(bind  7vel  #L( scl  send  talk-i  check-iris  10)) 

(bind  7time  #ltsd  send  talk-i  check-ins  10)) 

(bind  7guide  #Lfscl  send  talk-i  check-ins  1)) 

(bines  7b  #LiSd  intern  tsci  send  talk-i  cheovir.s  3i)i 
(,f  i eq  7b  >>>)  then 
(bind  fmsg-id  'MSG') 

(bind  7msg-id  #L(scl  intern  (user  stnng-append  7msg-id  7veh-idi)) 
(bind  7veh-id  #L(user  convert-stnng-to-integer  7veh-id)) 

(bmd  7utm-e  #L(ftoor  (user  convert-stnng-to-real  7utm-e))) 

(bind  7utm-n  #L(ftoor  (user  convert-stnng-to-real  7utm-nit) 

(bind  7cse  #L(user  convert-stnng  to-real  7cse)) 

(bind  ’’vel  #l(user  convert-stnng-to-real  7vel)( 

(bind  ihime  #L(user  convert-string-to-rea!  7tine)) 

(bind  7guide  #L(user  convert-stnng-to-mteger  7guide)) 

(modify  (schema  7msg-id 
(veh-id  7veh-id) 

(utm-e  7utm-e) 
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(utm-n  ’utm-n) 
(cse  ’cse) 
(vel  ?vel) 
(time  ’time) 
(guide  ’guide) 
(current  yes) 

) 


) 

) 

(retract  ’msg) 

(assert  (check-comm  ins) 
(check-comm  sym) 
(clock-update  yes) 


(defrule  read-imt-in 

(declare  (salience  lOCOj) 

’msg  <-  (msg-iris  ’a) 

(test  (eq  ’a  '<)) 

=  > 

(bind  ’b  #L(sd  intern  (scl  send  talk-i  check-iris  3)j) 

(if  (eq  ’b  <<<)  then 

(bind  ’org-utm-e  #L(scl.send  talk-i  check-iris  1C)) 

(bind ’org-utm-n  #L(scl.send  talk-i  check-ins  ICi) 

(bind ’veh-id  #l(scl  send  talk-i  check-iris  10)) 

(bind ’start-utm-e  #l(scl  send  talk-i  check-iris '0)) 

(bind  ’start-utm-n  #l(scl  send  talk-i  check-. r.s  1 0 j) 

(bind  ’goal-utm-e  #L(scl  send  talk-i  check-iris  10)) 

(bind ’goal-utm-n  #l(scl.send  talk-i  check-ins  10)) 

(bind  ’time  #L( scl  send  talk-i  check-iris  10)) 

(bind  ’b  #L(sd  intern  (scl  send  talk-i  check-ms  3:;) 

(if  (eq  ’b  <<<)  then 
(bind  ’mil  ’INIT’) 

(bind  ’mit  #L(sd  intern  (user  stnng-append  ’mit  ’veh-id))) 

(bind  ’map  "MAP") 

(bind  ’map  #L(scl  intern  (userstnng-append  ’map  ’veh-id))) 

(bind  ’cont ’CONTROL-) 

(bind  ’cont  #L(scl  intern  (user. stnng-append  ’cont  ’veh-id))) 

(bind  ’veh  ’VEH’) 

(bind  ’veh  #L(scl. intern  (user  stnng-append  ’veh  ’veh-id))) 

(bind  ’msg-id  ‘MSG’) 

(bind  >msg-id  #L(scl  intern  (user  stnng-append  ’msg-id  ’veh-id))) 
(bind  ’org-utm-e  #L(floor  (user  convert-string-to-real  ’org-utm-e))) 
(pnntout  1 1  ’org-utm-e) 

(bind  ’org-utm-n  #L(floor  (user  convert-strmg-to-real  ’org-utm-n))) 


142 


(printout  1 1  ’org-utm-n) 

(bind  ’veh-id  #l(user:convert-stnng-to-mteger  ’veh-id)) 
(bind  ’start-utm-e  #L(floor  (user  convert-strmg-to-real 
’start-utm-e))) 

(bind  ’start-utm-n  #L(floor  (user:convert-string-to-real 
?start-utm-n))) 

(bind  ’goal-utm-e  #L(fioor  (user  convert-string-to-real 
?goal-utm-e))) 

(bind  ’goal -utm-n  #l(floor  (user:convert-strmg-to-real 
’goal-utm-n))) 

(bind  ’time  #L(user  convert-string-to-real  ’time}) 

(bind  ’clock-id  #L(scl  make-instance  'user  myclock)) 
#L(scl:send  ’clock-id  .set-start-time  ’time) 

(assert  (schema  ’init 

(instanee-of  init) 

) 

(schema  ’map 

(instance-of  map) 

) 

(schema  ’cont 

(instance-ot  control) 

) 

(schema  ’veh 

(instance-of  veh-state) 

) 

(schema  ’msg-id 

(instance-of  veh-msg) 

) 

) 

(modify  (schema  ’init 

(org-utm-e  ’org-utm-e) 

(org-utm-n  ’org-utm-n) 

(veh-id  ’veh-id) 

(start  utm-e  ’start-utm-e) 

(start-utm-n  ’start-utrn-n) 

(goal-utm-e  ’goal-utm-e) 

(goal-utm-n  ’goal-utm-n) 


(type 

\ 

mil) 

1 

(schema  ’map 

(veh-id 

’veh-id) 

(utm-e 

’org-utm-e) 

(utm-n 

’org-utm-n) 

(ready 

send) 

(type 

\ 

map) 

; 

(schema  ’co.nt 
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(new-goa!  yes) 

(time  ’time) 

(old-time  ’time) 
tveh-id  ’veh-id) 
(dock-id  ?clock-id) 
(type  com) 

(seq  1) 

) 

(schema  ’veh 

(veh-id  ?veh-id) 
(utm-e  ?start-utm-e) 

(utm-n  ?start-utm-n) 

(type  veh) 

) 

(schema  ’msg-id 
(type  msg) 

(current  no) 


) 

) 

(retract  ’msg) 

(assert 

(check-comm  sym) 

(clock-update  yes) 

) 

) 

(defrule  process-map-loaded-msg 
(declare  (salience  1000)) 

’msg  <-  (msg-sym  ’a) 

(test  (eq  ’a  '')) 

=  > 

(bind  ’b  #L(sd  intern  (scl  send  talk  s  check  sym  3))) 

(if  (eq  ’b  I")  then 

(bind  ’cond  #L($cl. intern  (sd  send  taJk-s  check-sym  5))) 

(bind  ’veh-id  #L($cl  send  talk-s  check-sym  10)) 

(bind  ’b  #L(scl  intern  (sd. send  taik-s  check-sym  3))) 

(if  (and  (eq  ’b  'll1) 

(eq  ’cond  READY))  then 
(bind  ’map  'MAP') 

(bind  ’map  #L(scl  intern  (user  stnng-append  ’map  ’veh-id))) 
(modify  (schema  ’map 
(ready  ready) 

i 

> 

) 
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) 

(retract  ?msg) 

(assert  (check-comm  iris)) 

) 

(defrule  process-waypoint-in-msg 
(declare  (salience  1000)) 

?msg  <-  (msg-sym  ?a) 

(test  (eq  ?a  @)) 

(bind  ?b  #L(sd  intern  (scl  send  talk-s  .check-sym  3))) 

(if  (eq  ?b  @@@)  then 

(bind  7utm-e  #L(sd  send  talk-s  check-sym  5)) 

(bind  ?utm-n  #L(sd:send  talk-s  :check-sym  5)) 

(bind  7veh-id  #L(scl.send  talk-s  check-sym  10)) 
(bind  7seq  #L(scl  send  talk  s  check-sym  5)) 

(bind  7b  #L(sd. intern  (scl  send  talk-s  check-sym  3))) 
(if  (eq  ~b  <&@@)  then 
(bind  ’’way  "WAYPOINT") 

(bind  ?way  #L(scl  intern  (user. string-append 
(user  string-append  ’’way 
’veh-id 
) 

7seq 


) 

) 

(bind  7utm-e  #L(floor  (user  convert-stnng-to-mteger  7utm-e))) 
(bind  7utm-n  #L(floor  (user  convert-strmg-to-in’eger  7utm-n))) 
(bind  7veh-id  #L(floor  (user  convert-stnng-to-mteger  “«en-id)}) 
(bind  7seq  #L(floor  (user  convert-stnng-to-mteger  7seq;)) 
(assert  (schema  7way 

(instance-of  id) 

(instance-of  counter) 

(instance-of  cbj-type) 

(instance-of  location) 

(type  w-point) 

(utm-e  7utm-e) 

(utm-n  7utm-n) 

(veh-id  7veh-id) 

(seq  7seq) 

) 

) 


(if  (0  -  7seq)  then 

#L(scl  send  talk-i  put-waypomt  7veh-id  7utm  e  7utm-ni 
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) 

(retract  ’msg) 

(assert  (check-comm  iris)) 

) 

(defnjle  dean-up-waypomts 
(declare  (salience  6000)) 
(schema  ?way 

(type  w-point) 

(veh-id  ?veh-id) 

) 

(schema  ?msg 
(type  msg) 

(veh-id  ’veh-id) 

(guide  0) 

(current  yes) 

) 

(schema  ’veh 

(ven-id  ’veh-id) 

(type  veh) 

(guide  1) 

) 

=  ** 

(retract 

(schema  ?way 

(instance-of  id) 
(instance-of  counter) 
(instance-of  obj-type) 
(instance-ot  location) 

) 


) 

(defrule  clean-up-vehicle 

(declare  (saiience  50CC.; 

(schema  ’msg 
(type  msg) 

(veh-id  ’veh-id) 

(guide  0) 

(current  yes) 

/ 

(schema  ’init 

(veh-id  ih/eh-id) 

(type  mil) 

) 

(schema  ’map 

(veh-id  ’veh-id) 
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(type 

\ 

map) 

l 

(schema  ^cont 

(veh-id 

’veh -id) 

(type 

cont) 

) 

(schema  ?veh 

(veh-id 

?veh-id) 

(type 

veh) 

(guide 

1) 

) 

=> 

(retract 

(schema  ’mit 

(instance-of  init) 

) 

(schema  ’map 

(instance-of  map) 

) 

(schema  ’com 

(instance-o)  control) 

) 

(schema  ’veh 

(mstance-of  veh-state) 
) 


) 

(clefrule  dean-up-sym-msg 
(declare  (salience  500)) 
’msg  <-  (msg-sym  ?code) 


(retract  ’msg) 
(assert 

(check-comm  sym) 
(check-comm  ins) 
(dock-update  yes) 

) 

) 


(defrule  dean-up-ins-msg 
(declare  (salience  500)) 
’msg  <-  (msg-ms  ’code) 

=  > 

(retract  ’msg) 

(assert 


147 


(check-comm  ins) 

(check-comm  sym) 

(dock-update  yes) 

) 

) 

(defrule  load-map 

(declare  (salience  1000)) 

(sym-on  yes) 

(schema  ?map 
(utm-e  '’org-e) 

(utm-n  ?org-n) 

(veh-id  '’veh-id) 

(ready  send) 

(type  map) 

) 

=  > 

#L(scl.send  talk-s  load-map  7org-e  7org-n  ’veh-id) 
(modify 

(schema  I’map 
(ready  sent) 

) 

) 

(assert  (check-comm  sym)) 

) 

(defrule  start-path 

(declare  (salience  5000)) 

(schema  ’veh 
(type  veh) 

(guide  1) 

(veh-id  7veh-id) 

) 

(schema  ’’imt 

(org-utm-e  ’org-e) 

(org-utm-n  ?org-n) 

(start-utm-e  ?start-e) 

(start-utm-n  ’start-n) 

(goal-utm-e  9goal-e) 

(goal-utm-n  ’goal-n) 

(type  init) 

(veh-id  ’veh-id) 

) 

(schema  7map 

(veh-id  ’veh-ld) 

(type  map) 

(ready  ready) 
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) 

(schema  ’control 
(new-goal  yes) 

(veh-id  ’veh-id) 

(type  cont) 

) 

-> 

#L(scl:send  talk-s  :put-path  ’org-e  ’org-n  ’start-e  ?start-n  ’goal-e  ’goal-n 
’veh-id) 

(modify 

(schema  ?control 
(new-goal  no) 

) 

) 

) 


(defrule  send-new-waypcmt 
(declare  (salience  5000)) 

(schema  ’any 

(type  w-pomt) 

(veh-id  ’veh-id) 

(seq  ’seq) 

(utm-e  ’east) 

(u tm-n  ’north) 

) 

(schema  ’control 

(seq  ’seq-num) 

(veh-id  ’veh-id) 

(type  cont) 

(new-waypoint  yes) 

) 

(test  (and  (’seq-num  <  ’seq) 

('’seq-num  *3>  ’seq) 

) 

) 

=  > 

#l(scl  send  talk-i  put-waypoint  ’veh-id  ’east  ’north) 
(modify  (schema  ’control 
(seq  ’seq) 

(new-waypomt  no) 


(if  (’seq-num  =  1)  then 
(assert  (clock-update  yes)) 

) 

) 
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(defrule  update-vehicle 

(declare  (salience  1000)) 
(schema  ?veh-msg 
(type  msg) 

(veh-id  ?veh-id) 

(utm-e  ?utm-e) 

(utm-n  ?utm-n) 

(cse  ?cse) 

(vel  ’vel) 

(time  ?time) 

(guide  ’guide) 

(current  yes) 

) 

(schema  ’control 
(type  cont) 

(veh-id  ’veh-id) 

) 

(schema  ’veh-current 
(veh-id  ’veh-id) 

(type  veh) 

) 

=> 

(modify  (schema  ’control 

(time  ’time) 
(new -time  yes) 

) 

(schema  ’veh-current 
(utm-e  ’utm-e) 
(utm-n  ’utm-n) 
(cse  ’cse) 

(vel  ’vel) 
(guide  ’guide) 
(new-position  yes) 

) 

(schema  ’veh-msg 
(current  no) 

) 

) 

) 

(defrule  update-dock 

(declare  (salience  500)) 
’test  <-  (clock-update  yes) 
(schema  ’control 

(veh-id  ’veh-id) 

(time  ’time) 

(clock-id  ’dock-id) 
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(type  cont) 

) 

(schema  ’veh 

(veh-id  ’veh-id) 

(type  veh) 

(delta-time  ’delta-time) 

(new-position  no) 

) 

(test  (?deita-time  =  0)) 

=> 

(bind  ’current-time  #L(sd  send  ’clock-id  get-time)) 
(bind  ’delta-time  (’current-time  -  ’time)) 

(modify  (schema  ’control 

(time  ’current-time) 

) 

(schema  ’veh 

(delta-time  ’delta-time) 

) 

) 

(retract  ’test) 

) 

(defrule  reset-clock 

(declare  (salience  5000)) 

(schema  ’control 
(time  ’time) 

(old-time  ’old-time) 

(clock-td  ’dock-id) 

(new-time  yes) 

(type  cont) 

) 

(schema  ’veh 

(veh-id  ’veh-id) 

(type  veh) 

(delta-time  ’delta-time) 

(new-position  ?no) 

) 

=> 

(if  (eq  ’no  'NO)  then 

(bind  ’delta-time  (’time  -  ’old-time)) 

) 

#L(sci  send  ’clock-id  reset-last-time  ’time) 

(modify  (schema  ’control 
(old-time  ?time) 

(new-time  no) 

) 

(schema  ’veh 
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(delta-time  ’delta-time) 

(new-position  no) 

) 

) 

) 

(defrule  change-position 

(declare  (salience  5000)) 

(schema  ’veh 

(type  veh) 

(utm-e  ?utm-e) 

(utm-n  ?utm-n) 

(cse  ?cse) 

(vel  ?vel) 

(delta-time  ’delta-time) 

(new-posidon  no) 

) 

(test  (’delta-time  s  0)) 

=  > 

(bind  ’delta-dist  (’vel  *  ’delta-time)) 

(bind  ’utm-e  #L(f1oor  (>  ?utm-e  (•  ’delta-dist  (cos  ’cse))))) 
(bind  ’utm-n  #L( floor  (,  ’utm-n  ('  ’aelta-dist  (sin  ’cse,;,)) 
(modify  (schema  ’veh 

(utm-e  ’utm-e) 

(utm-n  ’utm-n) 

(delta-time  0) 

(new-posidon  yes) 

) 

) 

) 

(defrule  new-waypomt 

(declare  (salience  1000)) 

(schema  ’veh 


(type 

veh) 

(veh-id 

’veh-id) 

(new-posidon  yes) 

(utm-e 

?utm-e) 

(utm-n 

’utm-n) 

(guide 

D 

) 

(schema  ’control 
(type  corn) 
(seq  ’seq) 
(veh-td  ’veh-id) 

) 

(schema  ’any 
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) 

('  (car  (cdr  (cdr  (cdr  (car  (car  wave-paths)))))) 
1000000 000000000 
) 

(*  (car  (cdr  (car  (car  wave-paths))))  1 00000) 
(car  (car  (car  wave-paths))) 


) 

(setf  wave-paths  (append  (cdr  wave-paths) 

(list  (cdr  (car  wave-paths))) 

) 

) 

) 

(t 

(send  talk-s  put-waypoint 

(+  (*  (car  (cdr  (cdr  (car  (cdr  (car  wave-paths)))))) 

1 ocooooooooocoooooooo 

) 

(*  (car  (cdr  (cdr  (cdr  (car  (cdr  (car  wave-paths););))) 
1000000000000000 
) 

(*  (car  (cdr  (car  (cdr  (car  wave-paths)})))  1 00000) 
(car  (car  (cdr  (car  wave-paths)))) 

) 

) 

(setf  wave-paths  (cdr  wave-paths)) 

) 


) 

wave-paths 

) 


(defjn  add  id  (node-list  veh-id) 

(let  ((num-nodes  (length  node-list))) 

(dotimes  (x  num-nodes) 

(setf  node-list  (append  '-dr  node-list) 

(list  (cons  veh-id  (car  node-list))) 

) 

) 

) 

node-list 

) 

) 

(defun  add-seq-num  (node-list) 

(let  ((num-nodes  (length  node-list))  (seq  0)) 


(dotimes  (x  num-nodes) 

(self  node-list  (append  (cdr  node-list) 

(list  (cons  seq  (car  node-list))) 


) 

(setf  seq  (+  seq  1)) 

> 

node-list 

) 

) 

(defun  start-search-control 

0 

(search-control) 

) 

(defun  search-control 

0 

(load  "Ir-wave") 

(load  "chaosflavor*) 

(setf  talk-s  (make-instance  'mychaos)) 

(send  talk-s  start-server  "path") 

(do’ ((control  s  (send  talk-s  check-sym  1) 

(send  talk-s  check-sym  1) 

) 

) 

((setf  time-to-quit  'done') 

(send  talk-s  stop) 

) 

(cond 

((equal  control  s  *!") 

(setf  next-3  (send  talk  s  check-sym  3)) 

(cond 

((equal  next  3  *•"’) 

(setf  map  str-utm-e  (send  talk-s  check-sym  5)) 

(setf  map-str-utm-n  (send  talk-s  check-sym  5)) 

(setf  veh-id  (send  talk-s  check-sym  10)) 

(setf  next-3  (send  talk  s  check-sym  3)) 

(cond 

((equal  next-3  ’M!') 

(terpri) 

(pnnc  loading  map’) 

(setf  map-utm-e  (convert-stnng-to-mteger  map- str-utm-e)) 
(setf  map-utm-n  (convert-stnng-to-mteger  map-str-utm-n)) 
(setf  veh-map  (intern  (string-append 

(string  append  "MAP" 
map-st  r-u!m-e 
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(type  w-pomt) 

(veh-id  ’veh-id) 

(seq  ’seq) 

(utm-e  ’east) 

(utm-n  ’north) 

) 

-=> 

(it  (200  >  #L(let  ((dx  (-  ’east  ’utm-e)) 
(dy  (-  ’north  ’utm-n)) 

) 

(sqrt  (+  C  dx  dx)  (*  dy  dy))) 

) 

) 

then 

(modify 

(schema  ’control 

(new-waypom!  yes) 

) 


(modify  (schema  ’veh 

tnew-pcs/.ion  no> 
) 

) 

) 
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Mode:  LISP.  Package  USER;  Syntax  Common-lisp  -'- 
(Tide  Search  Control  Program 
Author  Shannon 
.Date  5  Jun  1989 

.Discnption:  This  program  controls  the  flow  of  the  search  algorithm 


(defvar  "done*) 

(setf  'done'  nil) 
(defvar  'maps') 

(setf  "maps'  nil) 
(defvar  'vehs') 

(setf  'vehs'  nil) 
(defvar  'wave-paths') 
(setf  'wave-paths'  nil) 


(defun  convert-to-utm  (node-list  map-u!m-e  map-utm-n) 

(let  ((num-nodes  (length  node-list))) 

(dotirr.es  (x  num-nodes) 

'cond 

(leq  x  (■  num-nodes  1)) 

(setf  node-list  -cdr  nooe-iist;) 

) 

(t 

(setf  (car  (car  node-list;;  inew-utm  (car  (car  node-ns:,,  map--tm-e); 
(setf  (car  (cdr  (car  node-list);)  (new-utm  (car  (cdr  (car  node-list,)) 
map-utm-n;) 

(setf  node-list  (append  (cdr  node-iist;  vlist  tear  node-i  s:,)); 

) 

) 

\ 

/ 

node-list 

) 

i 

(defun  send-waypomts  (wave-paths) 

(let  ((num-waves  (length  wave- paths))) 

(doDmes  (x  num-waves) 

(terpn) 

(cond 

((null  (car  wave-paths;) 

(setf  wave-paths  (cdr  wave-paths)) 

) 

((cdr  (cdr  (car  wave-paths))) 

(send  talk-s  put-waypoint 

(-  t"  (car  (cdr  (cdr  (car  <car  wave-pathsy ));) 

1 00000000900000000000 
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) 

map-str-utm-n 

) 

) 

) 

(sett  current-veh  (intern  (string-append  "VEH"  veh-id))) 
(do  ((maos  ‘maps’  (cdr  maps))! 

((or  (equal  veh-map  (car  maps)) 

(null  (cdr  maps)) 

) 

(cond 

((equal  ven-map  (car  maps)) 

(send  talk-s  put-ready 
(stnng-append  "READY" 
veh-id 


) 

) 

('null  (cdr  maps)} 

(setf  (symbol-value  veh-map)  (make-array  (102  1 02;;) 
(sett  "maps"  (cons  veh-map  "maps")) 

(sendtaik-s  p-t-ready 

(string-append  (load-map  100 
map-utm-e 
map-u  tm  -n 
"bin-slope  dat" 

(symbol-value  veh-map) 

) 

veh -id 
) 


) 

) 


(setf  (symbol-value  current-veh)  veh-map) 
(do  ((vehs  "vehs"  (cdr  vehs))) 

((or 

(eq  current-veh  (car  vehs)) 

(null  (cdr  vehs)) 

) 

(cond 

((null  (cdr  vehs))) 

(setf  ‘vehs’  (cons  current-veh  ‘vehs’}) 


) 

) 
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(terpri) 

(princ  "map  loaded") 

) 

) 

) 

) 

) 

((equal  control-s 

(serf  next-3  (send  talk-s  :check-sym  3)) 

(cond 

((equal  next-3  "@<2>(2>“) 

(sett  map-utm-e  (send  talk-s  check-sym  5)) 

(self  map-utm-n  (send  talk-s  check-sym  5)) 

(sett  start-utm-e  (send  talk-s  check-sym  5)) 

(sett  start-utm-n  (send  talk-s  check-sym  5)) 

(sett  goal-utm-m-e  (send  talk-s  check-sym  5)) 

(self  goal-utm-m-n  (send  talk-s  check-sym  5)) 

(sett  veh-id-str  (send  talk-s  check-sym  10)) 

(sett  next-3  (send  talk-s  check-sym  3)) 

(cond 

((equal  next-3  '@@@") 

(sett  map-utm-e  (convert-strmg-to-mteger  map-utm-e;; 
(sett  map-utm-n  (convert-stnng-to-mteger  map-utm-n)) 
(sett  start-utm-e  (convert-string-to-mteger  start-utm-e)) 

(sett  start-utm-n  (convert-stnng-to-mteger  start-utm-n)) 

(sett  goal-utm-m-e  (convert-stnng-to-mteger  goal-utm-m-e)) 
(set!  goal-utm-m-n  (oonvert-strmg-to-mteger  goai-utm-m-n;) 
(sett  veh-id  (convert-stnng-to-mteger  veh-id-str)) 

(sett  start-utm-e  (floor  (/ (-  start-utm-e  map-utm-e)  IOC))) 
(sett  start-utm-n  (floor  (/(- start-utm-n  map-utm-n)  100))) 
(sett  goal-utm-e  (floor  (/  (-  goal-utm-m-e  map-utm-e)  1 00))) 
(sett  goal-utm-n  (floor  (/(-  goal-utm-m-n  map-utm-n)  10C))) 
(self  current-veh  (intern  (strmg-append  "VEH"  veh-id-str))) 
(terpri) 

(pnnc  "planning  path") 

(terpri) 

(pnnc  start-utm-e) 

(terpri) 

(pnnc  start-utm-n) 

(terpri) 

(pnnc  goal-utm-e) 

(terpri) 

(prmc  goal-utm-n) 

(sett  'wave-paths*  (cons 

(add-seq-num 

(add-id 

(convert-to-utm 
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(append 

(wave  start-utm-e 
start-utm-n 
goal-utm-e 
goal-utm-n 
(symbol-value 
(symbol-vale  current-vet1) 

) 

! 

(list  (list  goal-utm-e  goal-utm-n)) 

) 

map-utm-e 

map-utm-n 

) 

veh-id 


) 

'wave-paths' 

I 


) 


) 


) 

) 

(cond 

((not  (atom  'wave-paths')) 

(sett  'wave-paths’  (send-waypomts  'wave  paths' i) 

) 

) 

) 


(defun  new-ufm  (num  map-org) 

(»  map-org  ('  num  100)  (random  100)) 

) 
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;;;  -*-  Package:  USER,  Mode:  LISP,  Syntax:  Common-lisp 

;TitJe:  Ir-wave  lisp 
.Author  Shannon 
Date  20  May  1989 

iDiscnption:  This  program  is  the  implimentation  of  a  wavefront  search  algorithm 
;  (wave  number -of-explored-cells  touched-flag) 

(defvar  'cost-array*) 

(defvar  'center-cell') 

(defvar  's-wave') 

(defvar  'g-wave') 

(defvar  'array-size') 

(defvar  'map-loaded*) 

(defvar  'map-array') 

(defvar  'start-loc') 

(defvar  "goal-loc”) 

(defvar  'parent-array') 


: ( serf  'map  size") 

(sett  'start-loc'  (2  2)) 

(setf  'goal-loc'  (10  10)) 

(defun  parent-p(x  y) 

(aref  'parent-array'  x  y)) 

(defun  set-new-cost(x  y  cost) 

(setf  (aref  'cost-array'  x  y)  cost)) 

(defun  se!-new-parent(x  y  parent-x  parent-y) 

(setf  (aref  'parent-array'  x  y)  (list  parent-x  parent-y))) 

(defun  retneve-cost(x  y) 

(aref  'cost-array  '  x  y)> 

(defun  retneve-parentlx  y) 

(aref  'parent-array  *  *yj) 

(detun  get-cost-from-map(x  y) 

(aref  'map-array'  x  y)) 

Idefun  load-map  (mapsize  map-e  map-n  mapfile  veh-map) 

(setq  input-stream  (open  mapfile  direction  input  byte-size  8  characters  nil)) 
(setf  map-loc  (♦  ('  (floor  (/  (-  map-e  41000)  1000))  10) 

('  (floor  (/  (-  mapn  60000)  1000))  3500))) 

(setf  'array-size'  (+  mapsize  2)) 

(setf  'map-array'  veh-map) 

(do  ((ycoord  0  ( »  ycoord  1))) 

I 
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((=  ycoord  'array-size')) 

(setf  (aref  'map-array"  0  ycoord)  -2) 

(sett  (aref  'map-array'  (-  'array-size'  1)  ycoord)  -2)) 

(do  ((xcoord  0  (+  xcoord  1))) 

((=  xcoord  'array-size')) 

(setf  (aref  'map-array'  xcoord  0)  -2) 

(setf  (aref  'map-array'  xcoord  (-  'array-size'  1))  -2) 

) 

(do  ((ycoord  1  (♦  ycoord  1))) 

((=  ycoord  (-  'array-size'  1 ))) 

(file-position  input-stream  map-loc) 

(do  ((xcoord  1  (+  xcoord  1))) 

((=  xcoord  (-  'array-size'  1))) 

(setf  slope  (read-byte  input-stream)) 

(setf  slope  (+  (/  (+  0  0  slope)  2)  1)) 

(cond 

((>  slope  15)  (setf  slope  -2))) 

(setf  (are f  'map-array'  xcoord  ycoord)  slope) 

) 

(setf  map-loc  (*  map-loc  350)) 

) 

(close  input-stream) 

(setf  'map-loaded'  yes) 

'READY' 

) 

(oelun  wave(siari-«  start-n  goal-e  goal-n  veh-map) 

(cond  ((equal  'map-loaded'  yes) 

(setf  'start-loc'  (list  start -e  stad-n)) 

(setf  'goal-loc*  (list  goal-e  goal-n)) 

(setf  'map-array'  veh-map) 

(read-terrain-data) 

(initial -expand) 

(no'mai-expand) 

(report-solution) 

) 

(t 

no-map-availabie))) 

(defun  report-solution() 

(  rend  (reverse  (follow-link  (first  ’center-cell’)  (second  'center-cell'))) 
(cdr  (follow-link  (first  'center-cell')  (third  'center-cell’))) 

) 

) 

(defun  follow-lmk  (post  pos2) 

(cond  ({equal  pcs’  pos2) 
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(cons  posl 
(tollow-link 
pos2 

(retrieve-parent  (first  pos2) 
(second  pos2))))))) 


(defun  read-terrain-data() 

(let  ((cost)  (start-x)  (start-y) 

(goal-x)  (goal-y)) 

(sett  'parent-array'  (make-array  (fist  'array-size'  'array-size'))) 
(sett  'cost-array'  (make-arTay  (list  'array-size'  'array-size'))) 
(copy-array-contents  'map-array'  'cost-array') 

(sett  start-x  (first  "start-loc')) 

(sett  start-y  (second  'start-loc')) 

(sett  goal-x  (first  'goal-loc')) 

(sett  goal-y  (second  'goal-loc')) 

(set-new-parent  start-x  start-y  start-x  start-y) 

(set-new-parent  goal-x  goal-y  goal-x  goal-y! 

(set-new-cost  start-x  start-y  -1)  wave-name 
(set  new-cost  goal-x  goal-y  0)  ,  wave-name 
(pnnt  'done-terrain-classi(ication) 

)) 


(detun  imtial-expandQ 
(do  () 

((sett 's-wave'  (imt-expand  -1  (list  'start-loc')))) 

) 

(do  () 

((sett  ’g-wave’  (mit-expand  0  (list  'goal-loc')))) 

) 

) 

(detun  imt-expand(wave-name  wave) 

.  retrun  a-wave 

(first  (expand-8  (car  wave)  wave-name))) 

(detun  expand-8  (pos  wave-name) 

(let  ((x  (first  pos)) 

(y  (second  pcs))) 

(orthog  expand  (-  x  1)  y  x  y  wave-name 


(orthog-expand  (+  x  1 )  y  x  y  wave-name 
(orthog-expand  x  (+  y  1 )  x  y  wave-name 
(orthog-expand  x  (-  y  1 )  x  y  wave-name 
(diag-expand  (-  x  1)  (+  y  1)  x  y  wave-name 
(diag-expand  (+  x  1)  (+  y  1)  x  y  wave-name 
(diag-expand  (+  x  1)  (-  y  1)  x  y  wave-name 
(diag-expand  (-  x  1)  (-  y  1)  x  y  wave-name 
(list  ml  0  0))))))))))) 

(defun  normal-expand() 

(do  () 

((or  (expand-s-wave) 

(expand -g-wave)) 

(pnnt  'wave-found)) 

) 

) 

(defun  expand-s-wave() 

(set-new-s-wave  (cycle-thru-wave's-wave*  -1  n-l))) 

(defun  expand-g-wave() 

(set-new-g-wave  (cycle-tnru-wave  'g-wave'  0  ml);) 

(defun  set-new  s-wave(new-wave-data) 

(setl  's  wave'  (car  new  wave-data)) 

(»=  (second  new-wave-data)  1)) 

(defun  set-new-g-wave(new-wave-data) 

(setf  'g-wave'  (car  new-wave- data)) 

(>=  (second  new- wave-data)  1)) 

(defun  cyde-thru-wavetwave  wave-name  t-wave) 

(cond  ((null  wave) 

(list  t-wave  0  ml)) 

(t  (let* 

((pos  (car  wave)) 

(x  (first  pos)) 

(y  (second  pos)) 

(a-parent  (retrieve-parent  x  yil 
(dx  (-  x  (first  a-parent))) 

(dy  (-  y  (second  a-parent))) 

(wave-data  (sub-expand  dx  dy  x  y  wave-name  t-wave)) 
(wave -data  t 

(cycle-thru-wave  (cdr  wave)  wave-name 
(add-back-to  wave  pos  wave-dataj))) 

(list  (first  wave-datal ) 
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(+  (second  wave-data  1)  (second  wave-data)) 

nil))))) 

(defun  add-back-to-wave  (pos  wave-data) 

(if  (>=  (third  wave-data)  3) 

(first  wave-data) 

(cons  pos  (first  wave-data)))) 


(defun  sub-expand(dx  dy  x  y  wave-name  wave) 

(cond  ((equal  dx  C) 

(sub-expandl  (+  y  dy)  x  y  wave-name  wave)) 

((equal  dy  0) 

(sub -expand2  (+  x  dx)  x  y  wave-name  wave)) 

(t 

(sub-expand3  (♦  x  dx)  (»  y  dy)  x  y  wave-name  wave)))) 

(defun  sub-expandl  (ny  x  y  wave-name  wave) 

(diag-expand  (*  x  1)  ny  x  y  wave-name 
(orthog-expand  x  ny  x  y  wave-name 
(diag-expand  (-  x  1)  ny  x  y  wave-name  (list  wave  0  0))))) 

(defun  sub-expand2(nx  x  y  wave-name  wave) 

(diag-expand  nx  (-  y  1)  x  y  wave-name 
(orthog-expand  nx  y  x  y  wave-name 
(diag-expand  nx  (*  y  1 )  x  y  wave-name  (list  wave  0  0))))) 

(defun  sub-expano3(nx  ny  x  y  wave-name  wave) 
(orthog-expand  nx  y  x  y  wave-name 
(diag-expand  nx  ny  x  y  wave-name 
(orthog-expand  x  ny  x  y  wave-name  (list  wave  0  0))))) 


(defun  orthog-expand  (x  y  px  py  wave-name  wave-data) 

(a-expand  x  y  px  py  1  4142  wave-name  wave-data)) 

(defun  diag-expand  (x  y  px  py  wave-name  wave-data) 

(a-expand  x  y  px  py  1  wave-name  wave-data)) 

(defun  a-expand  (x  y  px  py  amount  wave-name  wave-data) 

(if  (not  (parent-p  x  y)) 

(set-new-parent  x  y  px  py)) 

(let  ((cost  (retneve-cost  x  y))) 

(cond 

((and  (equal  cost  -1) 

(equal  cost  (other-wave-p  wave-name); 

(sett  ‘center-cell’ 
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(list  (list  x  y) 

(retrieve-parent  x  y) 

(list  px  py)» 

(list  (first  wave-data) 

(+  (second  wave-data)  1) 

(+  (third  wave-data)  1))) 

((and  (equal  cost  0) 

(equal  cost  (other-wave-p  wave -name))) 

(sett  'center-cell* 

(list  (list  x  y) 

(list  px  py) 

(retrieve-parent  x  y))) 

(list  (first  wave-data) 

(+  (second  wave-data)  1) 

(+  (third  wave-data)  1 ))) 

((and  (equal  (retneve-parent  x  y)  (list  px  py))  (>  cost  0)) 
(a-expandl  x  y  px  py  (-  cost  amount;  wave-name  wave-data)) 
(t 

(list  (first  wave-data; 

(second  wave-data) 

(*  (third  wave-data)  1 )))))) 


(defun  a-expandl  (x  y  px  py  new-cost  wave-name  wave-data) 
(cond  ((>  new-cost  0) 

(set-new -cost  x  y  new-cost) 
wave-data) 

(t 

(my-overflow  x  y  px  py  new-cost  wave-name 
(a-expand2  x  y  wave-name  wave-data)))j) 

(defun  a-expand2(x  y  wave-name  wave-data) 

(set-new-cost  x  y  wave-name; 

(list  (cons  (list  x  y)  (first  wave-data); 

(second  wave-data) 

(  +  (third  wave-data)  1 ))) 


(defun  other-wave-p  (wave-name) 
(if  (equal  wave-name  0) 

-1 

0)) 


(defun  my-overflow  (x  y  px  py  cost  wave-name  wave -data) 
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(cond  ((<  cost  0) 

(let*  ((nx  (♦  x  (-  x  px))) 

(ny  (+ y  (- y  py))) 

(costl  (retrieve-cost  nx  ny)} 

(new-cost  (+  cost  costl ))) 

(If  (not  (parent-p  nx  ny)) 

(set-new-parent  nx  ny  x  y)) 

(cond  ((and  (equal  (rntneve-parent  nx  ny)  (list  x  y))  (>  costl  0)) 
(cond  ((>  new-cost  0) 

(set-new-cost  nx  ny  new-cost) 
wave-data) 

(t 

(set-new -cost  nx  ny  wave-name) 

(my-overflow 

nx  ny  x  y  new -cost  wave-name 
(list  (cons  (list  nx  ny)  (first  wave-data)) 

(second  wave-data) 

(third  wave-data)))))) 

(t 

wave-data;) 

)) 

(t 

wave-data))) 
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APPENDIX  C  USER  INTERFACE 


The  user  interface  of  any  application  program  must  be  designed  so  that  novice  and 
experienced  users  alike  can  effectively  operate  the  program  with  little  or  no  help  from 
user’s  manuals  or  other  users.  This  is  achieved  by  a  thorough  and  efficient  design  of 
command  line  options,  popup  menus,  dials,  and  the  use  of  the  mouse.  This  appendix 
provides  instructions  on  starting  up  and  running  APS,  both  the  vehicle  simulator  and 
the  path  planner,  and  navigating  through  the  menus  and  operating  controls  of  the  sys¬ 
tem. 

I.  VEHICLE  SIMULATOR1 

The  section  covers  the  user  interface  to  the  vehicle  simulator  by  describing 
starting  procedures,  the  menu  system,  and  platform  controls. 

A.  COMMAND  LINE  OPTIONS2 

The  vehicle  simulator  is  started  by  typing  "aps"  followed  by  any  command 
line  options  and  pressing  RETURN.  There  are  currently  three  options  available  from 
the  command  line. 

•  Network  mode 

•  Test  mode 

•  Silent  mode 

Selection  of  the  network  mode  activates  the  networking  capabilities  of  the 
program.  In  this  mode  update  messages  are  sent  and  received  from  any  other  vehicle 
simulators  as  well  as  the  path  planner.  Vehicle  simulators  operating  on  different 
machines  will  be  able  to  share  information  regarding  the  other  platforms.  When  a 

^The  train  modifications  to  the  MPS  user  interface  are  in  die  driving  controls,  weapon  system  controls  and  additional  menu  options. 
The  entire  user  interface  i»  documented  here  for  completeness.  Where  the  MPS  interface  is  unmodified,  it  is  an  extract  of  Appendix 
A  of  ( FICHTN88). 

^The  code  *' 


tcsscs  the  command  line  arguments  is  contained  in  the  file  dccodc_argumcnis  c 


platform  fires,  changes  guidance  mode,  or  changes  course,  speed  or  altitude  (FOGM 
only),  a  message  is  sent  to  all  other  vehicle  simulators  and  to  the  AI  agent  updating 
the  local  database  for  the  appropriate  platform. 

Selection  of  test  mode  bypasses  some  of  the  cosmetic  portions  of  the  pro¬ 
gram.  Currently,  the  only  part  that  is  bypassed  is  the  opening  billboard  sequence. 

Selection  of  silent  mode  turns  off  the  bell  that  rings  to  indicate  acceptance 
of  input  from  the  user.  This  option  is  useful  far  demonstrations  when  the  ringing 
would  interfere  with  a  verbal  explanation  of  the  program. 

B,  POPUP  MENU  SYSTEM3 

Popup  menus  are  the  primary  source  of  user  control  over  the  state  of  the 
program.  There  are  currently  24  different  popup  menus  that  are  used  in  various  parts 
of  the  simulation.  If  a  selection  in  a  menu  is  not  allowed  or  meaningful  when  the  menu 
is  displayed,  the  selection  is  displayed  in  lower  case.  Otherwise  the  selection  is  com¬ 
pletely  uppercase.  Invalid  selections  are  retained  in  the  menu  so  that  .he  menus  al¬ 
ways  appear  in  the  same  order  and  format  every  time.  If  disallowed  selections  were 
omitted  completely,  users  would  tend  to  be  overwhelmed  by  the  number  of  different 
menu  formats. 

A  menu  is  displayed  and  the  selection  always  made  by  depressing  the 
right  mouse  button.  Roll-off  menus  are  emanded  by  moving  the  cursor  arrow  to  the 
right  when  a  menu  item  with  a  roll-off  submenu  (such  selections  have  a  small  arrow 
on  the  right-hand  side)  is  highlighted  The  following  is  a  detailed  explanation  of  each 
menu. 


3 

The  code  for  defining  *11  suuc  popup  menus  is  contained  in  the  rile  makepopups  c.  Code  for  displaying  an  1  processing  menu 
selections  is  con  lamed  in  the  following  files:  do_main.c,  do_dnving_menu.c,  do_flying_menu.c,  do_change_speed  c,  do_  intros  c, 
do_p*lhops.c,  do_quiOing.c,  do_select_are*.c,  do_the_add  c,  do_the_defaulu  c,  dn_the_deletc  c,  do_the_seicci.c.  and 
selcct_sight.c. 
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1.  Opening  Menus 


There  are  two  menus  that  make  up  the  opening  menu  set.  These 
menus  are  called  OPENING_ONE  and  OPENING_TWO.  Each  of  these  menus  con¬ 
tain  the  same  four  selections  as  follows: 

•  DISPLAY  INSTRUCTIONS 

•  GO  TO  SELECT  AREA  MENU 

•  EXIT  THE  PROGRAM 

•  ENTER  4SIGHT  (RESIZE  OPTIONS) 

OPENING_ONE  allows  the  user  to  select  any  one  of  these  options 
but  OPENING_TWO  disallows  the  first  option.  OPENING_TWO  is  displayed  if  the 
user  is  currently  looking  at  the  instruction  page. 

The  first  selection  displays  a  page  of  instructions  onthe  user  inter¬ 
face.  If  the  instruction  page  is  being  displayed  or  the  user  wishes  to  bypass  the  in¬ 
struction  page,  the  GO  TO  SELECT  AREA  MENU  selection  will  do  just  that.  To  exit 
the  program,  the  user  must  select  EXIT  THE  PROGRAM  and  a  small  menu  will  be 
displayed  with  the  following  selections: 

•  RETURN  TO  WHERE  YOU  WERE 

•  REALLY  QUIT 

If  the  user  desires  to  resize  or  move  the  simulation's  windows,  the 
option  ENTER  4SIGHT  (RESIZE  OPTIONS)  will  allow  him  to  accomplish  it.  After 
selecting  the  option,  the  windows  will  be  cleared  to  white  and  the  user  can  click  on 
the  menu  bar  and  move  or  resize  as  desired  using  normal  window  manager  functions. 

7.  Select  Area  Menu 

The  select  area  menu  is  active  whenever  the  35  KM  2D  map  is  dis¬ 
played.  It  contains  the  'bllowing  options: 

•  SELECT  AN  AREA  OF  THE  MAP 

•  GO  TO  MAIN  MENU 

•  EXIT  THE  PROGRAM 
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•  ENTER  4SIGHT  (RESIZE  OPTIONS) 

•  COLOR  SCHEME  -  BROWN  RAMP 

•  COLOR  SCHEME  -  MULTIPLE  COLORS 

•  COLOR  SCHEME  -  GREY  RAMP 

•  COLOR  SCHEME  -  RED  RAMP 

•  COLOR  SCHEME  -  GREEN  RAMP 

•  COLOR  SCHEME  -  BLUE  RAMP 

•  GO  TO  INTRODUCTION  SCREEN 

Selecting  GO  TO  MAIN  MENU  will  take  the  user  to  the  main  menu 
which  is  the  next  logicai  place  to  go  after  selecting  a  1GKM  area  in  which  to  operate. 

The  color  scheme  selections  change  the  way  the  terrain  is  colored. 
Each  color  scheme  has  eight  different  colors  that  are  based  on  the  elevation  at  that  lo¬ 
cation.  The  simulation  actually  uses  16  colors  to  create  a  checkerboarding  effect,  how¬ 
ever  the  user  is  only  shown  the  eight  primary  colors  in  the  color  ramp. 

The  last  selection  allows  a  user  to  return  to  the  introduction  screens 

if  he  desires. 

3.  Main  Menu 

The  main  menu  contains  the  following  ten  selections: 

•  PLACE  DEFAULT  SET  OF  PLATFORMS 

•  ADD  A  PLATFORM 

•  DELETE  A  PLATFORM 

•  SAVE  PLATFORMS  TO  A  FILE 

•  SELECT  A  PLATFORM  TO  OPERATE 

•  ENTER  4SIGHT  (RESIZE  OPTIONS) 

•  SELECT  ANOTHER  AREA  OF  THE  MAP 

•  PERFORM  PATH  OPERATIONS 

•  OBSTACLES  ON/OFF  => 

•  EXIT  THE  PROGRAM 


Selecting  the  first  option  (PLACE  DEFAULT  SET  OF  PLAT¬ 
FORMS)  will  display  another  menu  called  DEFAULT_MEN'U.  This  menu  contains  6 
selections  as  follows: 

•  ENTER  THE  FILENAME  FOR  YOUR  PLATFORMS 

•  CONVOY  -  10  GROUND  PLATFORMS 

•  CONVOY  -  10  GROUND  &  1  FOGM  PLATFORM 

•  JEEPS  -  20  LN  A  ROW 

•  DR.  ZYDA’S  CONVOY 

•  DR.  ZYDA’S  WiLDMAN  DEFAULTS 

if  the  user  selects  the  first  option,  a  small  window  is  displayed  on  the 
screen  which  prompts  the  user  for  the  filename.  If  valid  information  is  found  in  the  file, 
the  appropriate  platforms  are  added  to  the  simulation.  The  main  menu  is  then  redis¬ 
played. 

Selection  of  any  other  option  on  the  DEFAULT_MENU  results  in  the 
addition  of  predesignated  platforms  in  predesignated  locations.  These  selections  are 
useful  for  demonstration  purposes  and  for  persons  interested  in  getting  some  plat¬ 
forms  on  the  screen  very  quickly. 

The  information  for  the  default  sets  of  platforms  is  contained  in  data 
files  that  are  read  when  indicated  by  a  menu  selection.  The  complete  path  for  these 
files  is  contained  in  the  deader  file  “files. h". 

The  next  option  on  the  main  menu  is  ADD  A  PLATFORM.  Selecting 
this  option  displays  'he  following  menu: 

•  ALD A  COVERED  JEEP 

•  ADD  AN  OPEN  JEEP 

•  ADD  /  TRUCK 

•  ADD  A  TANK 

•  ADD  A  TOW  VEHICLE 

•  ADD  A  FOGM  MISSILE 

•  ADD  AN  ATTACK  HELICOPTER 

•  ADD  AN  OBSTACLE 


If  a  moving  platform  is  selected  (jeep,  truck,  tank,  TOW,  attack  heli¬ 
copter,  or  FOGM),  menus  are  displayed  requesting  an  initial  speed  and  direction  for 
the  platform.  If  an  obstacle  is  requested,  then  the  speed  and  direction  menus  are  by¬ 
passed.  The  FOGM  missile  defaults  to  an  initial  altitude  of  50  meters  above  the  ter¬ 
rain  at  the  point  where  it  is  placed.  After  completing  the  selections,  an  icon  is  placed 
in  the  center  of  the  screen  that  resembles  the  selected  platform  or  obstacle.  The  user 
can  then  move  the  icon  with  the  mouse  and  place  the  platform  by  clicking  the  right 
mouse  button.  After  placing  the  icon  on  the  screen,  the  main  menu  is  displayed  once 
again. 

Selecting  the  DELETE  A  PLATFORM  option  displays  the  following 

menu: 

•  DELETE  A  SINGLE  PLATFORM 

•  DELETE  ALL  PLATFORMS  ON  THE  SCREEN 

If  the  user  wants  to  delete  one  platform,  an  X  cursor  is  displayed  and 
the  user  can  click  on  the  desired  platform.  If  the  user  wants  >o  delete  all  the  platforms 
on  the  screen,  the  following  menu  is  displayed: 

•  NO,  DO  NOT  DELETE  ALL  THE  PLATFORMS 

•  YES,  DELETE  ALL  PLATFORMS 

The  appropriate  selection  from  this  menu  either  cancels  the  operation 
or  executes  it.  This  menu  prevents  a  user  from  deleting  vehicles  that  he  may  not  real¬ 
ly  want  to  delete. 

If  the  user  has  placed  platforms  on  the  screen  and  wishes  to  save 
them  to  a  file,  then  the  main  menu  selection  SAVE  PLATFORMS  TO  A  FILE  accom¬ 
plishes  this.  A  window  opens  that  prompts  the  user  for  the  filename.  If  the  path  is  cor¬ 
rect,  the  platforms  are  saved  to  the  File. 


The  next  selection  from  the  main  menu  is  SELECT  A  PLATFORM 
TO  OPERATE.  If  the  user  selects  this  option,  the  following  menu  is  displayed: 

•  ZOOM  IN  TO  ANY  LEGAL  GRID  SQUARE 

•  SELECT  A  PLATFORM  TO  OPERATE  RIGHT  NOW 

The  zoom  option  is  usually  necessary  if  platforms  are  close  to  each 
other  and  the  individual  icons  overlap.  By  zooming  into  the  lxl  kilometer  grid  square, 
the  user  can  more  easily  select  the  platform  he  desires.  If  the  platform  the  user 
wants  to  operate  is  clearly  visible,  then  the  second  selection  allows  the  user  to  select 
a  platform  immediately. 

The  SELECT  ANOTHER  AREA  OF  THE  MAP  option  returns  to 
the  SELECT_AREA  menu  and  redisplays  the  35KM  map. 

Selecting  PERFORM  PATH  OPERATIONS  from  the  main  menu  dis 
plays  a  submenu  containing  up  to  four  path  manipulation  functions.  These  functions 
are: 

•  DISPLAY  PATHS  ON/OFF  =5 

•  CONSTRUCT  PATH 

•  DELETE  PATH 

•  ASSIGN  VEHICLE  TO  PATH 

The  last  two  options  are  not  displayed  if  there  are  no  paths  to  delete 
or  no  vehicles  to  assign  to  a  path.  The  First  selection  is  a  toggle  that  turns  the  display 
of  paths  on  the  10K.M  map  on  and  off.  The  other  selections  allow  manipulation  of 
paths.  When  a  function  is  invoked  by  selecting  it,  specific  instructions  are  displa>ed 
in  the  lower  right  menu  window. 

4.  Operating  Menus 

Operating  menus  are  available  when  a  platform  has  been  selected 
and  is  being  driven  by  the  user.  They  generally  affect  the  characteristics  of  the  3D 
terrain  display  or  how  the  vehicle  is  being  controlled. 


a.  Driving  Menu.  This  menu  is  called  OPERATE_DRIVE.  It 
contains  ten  selections: 

•  DO  NOTHING 

•  RETURN  TO  MAIN  MENU 

•  CHANGE  ALL  PLATFORMS’  SPEEDS 

•  EXIT  THE  PROGRAM 

•  ENTER  4SIGHT  (RESIZE  OPTIONS) 

•  POP  WINDOWS 

•  CHANGE  VIEW 

•  ADVANCED  OPTIONS  => 

•  AUTOPILOT  ON/OFF  =» 

•  GUIDANCE  ON/OFF  =* 

The  first  selection  is  presided  in  case  the  user  pushes  the  right 
mouse  button  and  he  does  not  desire  to  do  anything.  The  second  selection  returns  the 
user  to  the  main  menu. 

The  third  selection  causes  another  menu  to  pop  up  that  allows  the  us¬ 
er  to  select  a  speed  for  all  the  platforms  currently  in  the  simulation.  The  allowable 
speeds  are  from  zero  to  65  miles  per  hour.  There  is  also  a  selection  that  will  do  noth¬ 
ing  and  return  directly  to  the  simulation.  Changing  all  the  speeds  is  convenient  when 
the  user  wants  to  have  a  convoy  of  platforms  proceed  at  identical  speeds.  Also,  by  se¬ 
lecting  zero  miles  per  hour,  all  platforms  are  effectively  frozen  and  their  configuration 
can  be  studied  by  viewing  them  from  a  FOGM  missile  or  other  platform. 

The  POP  WINDOWS  selection  brings  the  four  windows  of  the  simu¬ 
lation  into  view  if  any  of  them  are  obscured  from  view  by  other  processes  that  are  run¬ 
ning  on  the  machine. 

If  the  CHANGE  VIEW  option  is  selected,  a  submenu  containing  dif¬ 
ferent  operating  modes  is  presented.  All  platforms  have  at  least  three  options: 

•  NORMAL  VIEW  -  Normal  commander’s  view,  all  dials  including  course  and 

speed  are  active. 
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•  DRIVER’S  STATION  -  Activates  mouse  joystick  (Figure  C-l).  for  driving  the 

platform.  In  this  mode  moving  the  mouse  move  the  steering  cursor  which 
controls  the  steering  and  throttle.  The  corresponding  course  and  speed  di¬ 
als  are  deactivated. 

•  BINOCULARS  -  Gives  view  through  a  pair  of  variable  power  binoculars. 

An  additional  selection  is  presented  for  each  weapon  system  type 
and  munition  combination  carried  by  the  platform,  i.e.,  for  a  TOW  vehicle  a  TOW  se¬ 
lection  is  displayed  along  with  the  normal  three  views. 

The  ADVANCED  OPTIONS  selection  brings  up  the  following  menu: 

•  TOGGLE  SINGLE/DOUBLE  BUFFER  MODE 

•  TARGETING  MODE  TEST  (ONCE) 

•  TERRAIN  DRAWING  OPTIONS 


The  first  selection  toggles  the  graphics  hardware  between  single¬ 
buffer  and  doublebuffer  modes.  In  doublebuffer  mode,  all  drawing  is  done  in  a  separate 
area  of  memory  from  the  display  memory,  When  the  function  swapbuftersf)  is  called, 
the  pointer  to  this  area  and  the  pointer  to  the  display  buffer  are  switched,  thereby 
swapping  the  new  picture  for  the  old  picture.  This  is  how  smooth  motion  is  simulated. 
If  a  user  is  interested  in  what  order  the  individual  picture  elements  are  drawn  on  the 
screen,  then  by  selecting  singlebuffer  mode,  he  can  see  the  pictures  while  they  are  be¬ 


ing  drawn. 


TURN  LEFT 


ACCELERATE 


TURN  RIGHT 


BRAKE 

Figure  C-l  Mouse  Steering  Cursor 


Targeting  mode  test  allows  a  user  to  see  how  the  simulation  deter¬ 
mines  if  a  target  is  in  the  crosshairs  of  the  FOGM  missile  during  targeting.  After  se¬ 
lecting  the  option,  the  next  time  targeting  is  attempted,  the  view  will  be  cleared  to 
white  and  all  visible  platforms  will  be  drawn  without  lighting,  shading,  or  hidden  sur¬ 
face  removal.  The  resulting  picture  is  displayed  for  three  seconds  and  then  normal  op¬ 
eration  commences.  This  option  is  reset  each  time  it  is  used. 

The  TERRAIN  DRAWING  OPTIONS  option  is  a  roll-off  menu. 
When  the  user  moves  the  cursor  tow-ards  the  right  side  of  the  words  TERRAIN 
DRAWING  OPTIONS,  the  following  menu  is  displayed: 

•  DETAILED  ERRAIN 

•  DISTANCE  ATTENUATION  -  NORMAL 

•  DISTANCE  ATTENUATION  -  BOUNDARIES  DISPLAYED 

The  default  terrain  drawing  option  is  DISTANCE  ATTENUATION  - 
NORMAL.  This  drawing  option  establishes  three  zones  in  front  of  the  driven  platform 
and  reduces  the  number  of  polygons  that  are  displayed  in  each  zone.  The  zone  closest 
to  the  viewer  is  displayed  with  100x100  meter  polygons,  the  greatest  resolution  avail¬ 
able.  The  next  zone  uses  200x200  meter  polygons  and  the  last  zone  uses  400x400 
meter  polygons.  The  selection  DISTANCE  ATTENUATION  -  BOUNDARIES  DIS¬ 
PLAYED  draws  the  boundaries  between  z°nes  in  cyan  so  the  user  can  see  where 
they  are.  The  selection  for  DETAILED  TERRAIN  draws  100x100  meter  polygons 
throughout  the  three  zones.  Users  notice  a  significant  dec  re  a.  in  the  frames  per  sec¬ 
ond  rate  when  this  option  is  selected.  If  singlebuffer  mode  is  also  enabled  during  de¬ 
tailed  terrain  drawing,  the  algorithm  that  is  used  to  draw  the  terrain  becomes  more 
obvious. 

The  GUIDANCE  ON/OFF  toggles  the  guidance  mode  of  the  current¬ 
ly  selected  platform.  It  invokes  the  actions  described  in  paragraph  C  of  chapter  three. 
A  indicator  light  in  the  upper  right  window  is  also  toggled  to  reflect  the  current  guid¬ 
ance  mode. 


The  AUTOPILOT  ON/OFF  option  works  much  the  same.  It  toggles 
the  platform’s  autopilot  and  its  indicator  light  on  and  off. 

b.  Flying.  There  are  three  menus  that  make  up  the  flying  menu 
set.  These  menus  are  called  OPERATE_FLY_ONE,  OPERA  TE_FLY_TWO,  and 
OPERATE_FLY  _THREE.  This  menu  contains  the  seven  selections  as  follows: 

•  DO  NOTFUNG 

•  DETACH/RESUME  OPERATING 

•  RETURN  TO  MAIN  MENU 

•  CHANGE  ALL  PLATFORMS’  SPEEDS 

•  EXIT  THE  PROGRAM 

•  ENTER  4SIGHT  (RESIZE  OPTIONS) 

•  TOGGLE  TARGET  TRACKING 

•  ADVANCED  OPTIONS 

Many  of  these  options  are  exact  duplicates  of  the  options  on  the  driv¬ 
ing  menu.  However,  the  DETACH/RESUME  OPERATING  and  TOGGLE  TARGET 
TRACKING  options  are  different. 

The  DETACH/RESUME  OPERATING  option  allows  a  user  to  de¬ 
tach  the  cursor  from  the  simulation  while  flying.  During  fixing,  the  cursor  is  restricted 
to  the  simulation  window  because  the  mouse  controls  where  the  nose  camera  of  the 
FOGM  missile  is  pointed.  Using  this  option,  the  user  can  point  the  camera  where  he 
wants  to  look  and  then  free  the  mouse.  To  return  to  the  simulation,  the  user  must  se¬ 
lect  the  same  option  once  again. 

If  the  user  has  a  ground  platform  in  the  crosshairs  of  the  FOGM  mis 
sile  and  he  wants  to  target  it,  he  must  make  the  TOGGLE  TARGET  TRACKING  se¬ 
lection  from  the  menu.  If  a  platform  was  in  the  crosshairs,  then  the  missile  w  ill  lock  on 
and  track  the  platform.  If  the  user  wants  to  release  the  missile  from  tracking  mode 
then  another  selection  will  turn  off  target  tracking. 


/ 
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C.  DIALS4 

The  dial  box  that  is  supplied  by  SGI  has  eight  dials  numbered  from  zero  to 
seven.  They  are  organized  in  two  columns  and  four  rows.  The  numbering  scheme  is 
from  left  to  right,  bottom  to  top  so  the  lower  left  dial  is  zero,  the  lower  right  is  one  and 
the  upper  right  is  seven. 

The  Autonomous  Platform  Simulator  uses  these  dials  in  basically  three 
configurations;  one  for  driving  a  platform  that  has  no  weapon  system,  a  second  for 
driving  a  weapon  equipped  platform  and  a  third  for  flying  the  FOGM.  When  the  vehi¬ 
cle  i  being  driven  using  the  mouse  joystick,  the  course  and  speed  dials  are  inactive. 
When  looking  through  the  w-eapon  sight  cf  a  platform  dials  one  and  three  affect  the  az¬ 
imuth  and  elevation  respectfully  of  the  weapon  system.  When  in  normal  view  mode 
dials  six  and  seven  perform  this  function  and  the  weapon  is  controlled  independently 
of  vehicle  course  or  viewing  angle. 

1.  Driving  Dial  Configuration 

The  dials  for  driving  (Figure  C-2)  are  configured  as  follows: 

•  DIAL  0- Course 

•  DIAL  1  -  Viewing  direction  or  weapon  azimuth  if  a  sight  is  active 

•  DIAL  2  -  Speed 

•  DIAL  3  -  Viewing  elevation  or  weapon  elevation  if  a  sight  is  active 

•  DIAL  4  -  Hour  of  the  day 

•  DIAL  5  -  Month  of  the  year 

•  DIAL  6  -  Traverse  weapon  system  when  not  looking  through  sight 

•  DIAL  7  -  Elevate  weapon  system  when  not  looking  through  sight 

The  course  is  the  direction  of  travel  of  the  platform  which  is  displayed 
in  degrees.  The  viewing  direction  is  the  direction  the  driver’s  head  is  looking  left  to 
right  in  relation  to  the  course.  When  the  course  is  changed,  the  viewing  angle  changes 
accordingly.  Speed  is  the  speed  of  the  platform  in  miles  per  hour.  View  elevation 

*The  code  for  initializing  the  dials  is  contained  in  the  following  files,  sctcontrols.c  and  sctcontrols_ fogm.c  Code  for  handling  input 
from  the  diais'  movements  is  contained  in  the  following  files,  hr-n  die  controls  c.  handlecontroh  J\»gm  c,  and  handlecontrols^pamal  c 
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moves  the  driver’s  view  up  and  down.  The  hour  of  the  day  and  month  of  the  year  de¬ 
termine  the  location,  color,  and  intensity  of  the  sun.  Figure  C-2  is  a  picture  of  the  dial 
box  with  the  dials  labeled  for  driving. 

2.  Flying  Dial  Configuration 

The  dials  for  flying  are  configured  as  follows: 

•  DIAL  0  -  Course 

•  DIAL  1  -  Altitude 

•  DIAL  2  -  Speed 

•  DIAL  3  -  Not  Used 

•  DIAL  4  -  Hour  of  the  Day 

•  DIAL  5  -  Month  of  the  Year 

•  DIAL  6  -  Not  Used 

•  DIAL  7  -  Not  Used 

Many  of  the  dials  are  identical  to  the  driving  dial  configuration  except  for  al¬ 
titude  which  is  self-explanatory.  Figure  C-3  is  a  picture  of  the  dial  box  with  the  dials 
labeled  for  flying. 

D.  Mouse5 

The  mouse  has  many  uses  throughout  the  simulation.  Its  use  can  be  bro¬ 
ken  down  into  basically  six  groups: 

•  Popup  menu  activation  and  selection 

•  Operating  area  selection 

•  Platform  icon  placement  and  selection 

•  FOGM  missile  nose  camera  control 

•  Mouse  joystick  driving  control 

•  Weapon  rangefinder  and  firing  controls 


Code  lor  handling  the  operations  of  the  selections  is  contained  in  the  file  sclect_area_menu  c.  Code  for  handling  platform  icon 
placement  is  contained  in  the  files  do_the_add  c  and  addveh.c.  Code  for  driving  using  the  mouse  as  a  joystick  is  contained  m 
sciup_for_dn\.ing  u  Cxie  for  handling  K)G\1  missile  nose  camera  control  is  churned  in  th~  files  handlcvontruU Jogm  c  and 
handle; untr« 'Is _partia!  c 
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Figure  C-2  Dial  Box  With  Dials  Labeled  For  Driving 


Figure  C-3  Dial  Box  With  Dials  Labeled  For  Flying 
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When  operating  a  platform  using  the  dials  or  mouse  joystick  the  left  and 
middle  mouse  buttons  control  the  magnification  of  the  view  by  zooming  OUT  or  IN  re¬ 
spectively  as  shown  in  Figure  C-4.  When  looking  through  the  sight  of  a  weapon  sys¬ 
tem  the  left  and  middle  mouse  buttons  function  as  a  rangerfinder  and  trigger.  This 
arrangement  is  shown  in  Figure  C-5. 

The  mouse  is  used  throughout  the  simulation  to  activate  popup  menus  and  to  se¬ 
lect  options.  One  of  these  options  is  to  select  an  area  from  the  large  database.  A 
10x10  kilometer  red  square  is  displayed  or.  the  35x?5  kilometer  database  and  the 
mouse  is  used  to  move  the  square  to  the  desired  location.  Platforms  are  placed  and 
selected  on  the  screen  with  the  mouse. 

The  nose  camera  of  the  FOGM  missile  is  controlled  with  the  movement  of  the 
mouse.  This  gives  the  user  very  fine  control  over  targeting  and  viewing  direction. 

E.  Keyboard6 

The  keyboard  is  only  used  to  accept  filenames  from  the  use:.  Ail  other  user 
input  is  through  iliv.  popup  menus,  dials,  or  mouse. 


C’*«jc  for  handling  filename  input  is  o.tuained  in  ihc  files  get  name  c  and  do  ».har  v 
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Figure  C-4  Mouse  Button  Assignments  *  Normal  View 


II.  PATH  PLANNER 


The  path  planner  portion  of  APS  is  not  a  stand  alone  process,  it  requires  the  ve¬ 
hicle  simulator  to  be  running.  This  section  covers  how  to  run  the  path  planner  portion 
of  the  vehicle  simulator  by  describing  starting  and  stopping  procedures. 

A.  INITIAL  REQUIREMENTS 

The  path  planner  requires  that  seven  files  be  loaded  across  two  Symbolics 
workstations.  The  following  files  are  required  on  SYM4,  where  ART  resides. 

•  pp-control.art 

•  irisflavor3.1isp 

•  chaosflavor.lisp 

•  comm-functions.lisp 

•  clock-functions. lisp 

•  def-interface.lisp 

The  above  files  do  not  have  to  be  loaded  to  begin  with,  but  must  be  available  for  file 
access.  The  following  files  are  required  on  another  Symbolics  workstation. 

•  big-slope.bin 

•  search-control. lisp 

•  chaosflavor.lisp 

•  comm-functions.lisp 

•  lr-wave.lisp 

B.  START  PROCEDURES 

The  path  planner  requires  several  preconditions  to  run  properly.  Since  the 
path  planner  is  not  a  stand  alone  program,  APS  must  be  brought  up  first  in  network 
mode.  The  path  planner  may  be  started  anytime  after  APS  has  passed  the  initial 
screen  display.  Starting  the  path  planner  is  divided  into  two  sections.  These  sections 
are  starting  the  path  planner  control  program,  and  starting  the  search  control  program. 


1.  Starting  the  Path  Planner  Control  Program 

On  SYM4,  enter  ART  by  typing  the  SELECT:  button,  then  typing  A. 
Load  pp-control.art  in  the  ART  shell.  Reset  ART  by  clicking  the  left  mouse  button  on 
reset.  Left  mouse  click  on  run.  The  program  will  query  the  user  as  to  which  Symbolics 
workstation  the  search  algorithm  is  loaded.  After  ensuring  that  the  search  control  pro¬ 
gram  is  started  on  the  other  Symbolics  workstation,  select  the  appropriate  letter.  The 
program  will  then  query  the  user  as  to  which  IRIS  graphics  workstation  the  vehicle 
simulation  is  running  on.  After  ensuring  that  the  simulation  is  already  running  in  the 
network  mode,  select  the  appropriate  letter  from  the  menu.  The  path  planner  is  now 
running  on  its  own  and  needs  no  further  user  interaction. 

2.  Starting  the  Search  Control  Program 

The  search  control  program  is  loaded  onto  any  Symbolics  worksta¬ 
tion.  ether  than  SYM4  where  the  path  planner  control  program  is  loaded.  To  start  the 
search  program,  load  search-control. lisp.  Then  in  the  LISP  listener  enter  (start- 
search-control.).  The  program  will  respond  by  loading  all  of  its  communications  and 
search  files,  then  initiate  a  wait  for  communications  from  the  path  planner  control  pro¬ 
gram  on  SYM4.  No  further  user  interaction  is  required. 

C,  STOPPING  THE  PATH  PLANNER 

When  the  user  is  finished  with  the  path  planner,  it  is  halted  by  using  the 
META.  CONTROL,  and  ABORT  keys  simultaneously.  Next,  on  SYM4.  the  user  en¬ 
ters  the  dynamic  LISP  listener  and  sets  the  user  package  to  ACL  (ART  Common  Us¬ 
er),  and  clears  the  communications  paths  by  entering  the  follow  ing: 

•  (scLsend  talk-i  :stop-iris) 

•  (scLsend  talk-s  :stop) 

The  search  control  program  is  halted  in  an  identical  manner  as  the  path  planner 
control  program,  but  there  is  no  need  to  enter  a  special  LISP  package  to  clear  the  com¬ 
munications  path.  The  communications  path  for  the  search  control  program  is  cleared 
by  entering  (send  talk-s  :stop). 
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APPENDIX  D  KNOWN  BUGS  and  SUGGESTED  CODE  IMPROVEMENTS 


1.  The  timer  is  currently  reset  when  a  vehicle  is  selected/reselected  to  operate 
from  the  main  menu.  This  causes  errors  in  timed  events  on  the  event  list  such  as 
rounds  in  flight,  safety  reset,  etc.. 

2.  The  Cobra  attack  helicopter  is  controlled  the  same  as  a  ground  vehicle. 

3.  Guidance  for  LOS  guided  weapons,  specifically  the  TOW.  uses  the  current 
weapon  azimuth  and  elevation,  not  the  parameters  at  the  moment  of  firing  like  a  bal¬ 
listic  round.  This  is  correct  but  still  fails  to  move  the  round  onto  the  LOS  at  the 
crosshairs  of  the  sight  reticle.  In  check_round_in_fllght(),  the  round  should  be  moved 
to  its  new  updated  position  by  moving  towards  the  current  point  of  aim  while  being 
kept  within  the  turning  limits  of  the  missile  control  system. 

4.  A  separate  eye  position  should  be  added  to  provide  additional  viewpoints  on 
each  vehicle.  Each  vehicle  should  have  t  eye  position  for:  normal  view  (TC>.  driver's 
view,  and  weapon  view.  This  should  be  accomplished  by  adding  the  following  data 
structure: 

#define  TC_FOSIT!ON  0 

#define  DRIVER_POSITION  1 

#define  WEAPONPOSITION  2 

float  eye_positlon[vehtype][view_position][x,y,z] 

5.  The  FOGM  controls  no  longer  work  correctly.  The  pan  direction  is  reversed 
and  the  course  is  fixed  a;  90  degrees. 

6.  The  network(SEND_END_MESSAGE)  function  causes  remote  simulators  to 
crash.  Since  net  ids  are  now  unique,  the  range  of  ids  can  no  longer  be  calculated. 
Therefore,  the  terminating  simulator  must  send  a  delete  message  for  each  of  its  local 
platforms  when  terminating. 

7.  In  some  cases,  the  autopilot  will  cause  a  platform  to  endlessly  orbit  the 
goal.  Normally  a  platform  approaches  a  guide  point  head-on  and  stops  or  turns.  If 


thr*  vehicle  is  outside  the  stopping  distance  and  facing  away  from  the  goal  when  the 
autopilot  is  engaged,  then  the  vehicle  can  get  into  a  situation  where  it  passes  by  the 
guide  point  before  it  completes  its  tum  to  head  for  it.  This  results  in  a  circular  path 
around  the  guide  point.  This  should  be  taken  care  of  when  the  autopilot  is  made  more 
accurate  to  handle  obstacle  avoidance. 

8.  The  display  limiting  algorithm  in  drawterrain  doesn’t  work  properly  for  the 
extremely  narrow'  field-of-view  used  for  the  13X  TOW  sight.  At  certain  angles  not 
enough  terrain  is  drawn  so  some  blue  sky  background  shows  through. 

9.  Calculating  surface  normals  for  100  squares  across  and  up  requires  101  ele¬ 
vation  data  points.  The  101st  elevation  doesn’t  exist,  resulting  in  bad  normals  along 
the  top  row  and  right  column.  This  was  fixed  temporarily  by  extending  the  100th  ele¬ 
vation  out  to  also  be  the  101st  elevation  which  creates  a  light  band  of  terrain  in  these 
border  areas.  The  algorithm  should  be  changed  to  either  get  the  101st  elevation  or 
extrapolate  it  based  on  99th  and  100th  elevations. 

10.  All  matching  of  platform  ids  is  done  by  linear  search  through  the  platform 
list.  This  is  not  a  problem  with  only  a  handful  of  vehicles,  but  would  cause  serious  de¬ 
lays  for  a  more  realistic  number  of  platforms.  This  should  be  replaced  by  a  hash  table 
using  platform  id. 
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